一、Redis集群模式的故障發現

Redis集群模式故障發現過程有主觀下線與客觀下線。

主觀下線簡單來說就是我這個節點認為你故障了。

客觀下線則是集群中大多數節點認為你故障了。

這些判定與狀態的同步均通過Gossip協議PING/PONG來通信。

主觀下線流程

• @1 定時向集群中其他節點發送PING消息
• @2 超過時間（cluster-node-timeout）未收到接受節點PONG響應消息
• @3 認為該接受節點存在故障，標記為主觀下線狀態pfail

客觀下線流程

• @1 Gossip協議PING/PONG通信

攜帶集群1/10的其他節點狀態

當然也包含主觀下線節點的信息

• @2 接受節點維護故障節點下線報告

只處理發送為主節點的請求，從節點不處理

不存在故障節點下線報告，新增下線報告

已存在故障節點下線報告，更新報告時間

• @3 嘗試故障節點的客觀下線邏輯

每次收到其他節點的故障狀態pfail時，均會嘗試客觀下線

監測故障下線報告是否過期，過期的報告將被刪除

報告時間超過cluster-node-timeout*2未被更新將被移除

下線報告數量小于持有槽主節點的數量的二分之一，退出客觀下線

下線報告數量大于持有槽主節點的數量的二分之一，標記客觀下線

向集群廣播一條fail消息（標記客觀下線立即生效、故障從節點發起故障轉移流程）

二、Redis集群模式的故障轉移

Redis集群模式從節點的作用用于災備，主節點故障時能夠替換頂上去。

• Redis的從節點當然也不例外。
• 多個從節點誰去替換主節點？

選舉邏輯以及選舉失效是怎么樣的？

故障轉移流程

從節點中復制的偏移量越大，替換主節點的優先級越高。

從節點獲得持有槽的主節點一半以上的選票，可替換為主節點。

從節點向集群廣播PONG消息，通知該變更。

三、常見緩存代理架構方案簡述

Redis的集群模式客戶端直連集群，不需要額外的組件，運維難度較低。

由于集群中每個實例都需要保存路由信息，彼此不斷傳播通信更新，也造成通信成本進而影響集群規模。

Redis的集群模式也會造成客戶端需要重定向，帶來復雜性。

因此，緩存代理模式可以解決這種復雜性，當然組件也會增多。

客服端：兼容RESP協議的輕量級客戶端。

集群代理：負責域客戶端建立連接，以及轉發請求到對應的槽位和實例節點。

元數據中心：主要負責存儲槽位與實例對應路由信息以及健康檢查心跳探測。

集群模式一：集群部署主從架構，需要元數中心負責心跳的健康監測，主從節點的HA，當主節點故障切換從節點接管。

集群模式二：集群部署Raft組，不需要額外的HA心跳監測，集群自閉環，三個節點一組成本較高。

模式一

模式二

兼容RESP協議的輕量級客戶端與代理建立長鏈接。

發送讀寫請求到代理層，代理根據路由規則將key路由到對應集群的槽位。

管理平臺可對元數據信息、槽位分配、代理以及集群部署運維等進行管理。

可視化白屏化對整個集群的監控、告警、大key等水位監控告警。