一、Redis集群模式的故障發(fā)現(xiàn)

Redis集群模式故障發(fā)現(xiàn)過程有主觀下線與客觀下線。

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

客觀下線則是集群中大多數(shù)節(jié)點認為你故障了。

這些判定與狀態(tài)的同步均通過Gossip協(xié)議PING/PONG來通信。

主觀下線流程

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

客觀下線流程

• @1 Gossip協(xié)議PING/PONG通信

攜帶集群1/10的其他節(jié)點狀態(tài)

當然也包含主觀下線節(jié)點的信息

• @2 接受節(jié)點維護故障節(jié)點下線報告

只處理發(fā)送為主節(jié)點的請求，從節(jié)點不處理

不存在故障節(jié)點下線報告，新增下線報告

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

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

每次收到其他節(jié)點的故障狀態(tài)pfail時，均會嘗試客觀下線

監(jiān)測故障下線報告是否過期，過期的報告將被刪除

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

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

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

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

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

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

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

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

故障轉移流程

從節(jié)點中復制的偏移量越大，替換主節(jié)點的優(yōu)先級越高。

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

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

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

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

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

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

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

客服端：兼容RESP協(xié)議的輕量級客戶端。

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

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

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

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

模式一

模式二

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

發(fā)送讀寫請求到代理層，代理根據(jù)路由規(guī)則將key路由到對應集群的槽位。

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

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