建站
咨詢
售后
建站咨詢
新聞中心
一、Redis集群模式的故障發(fā)現(xiàn)
Redis集群模式故障發(fā)現(xiàn)過程有主觀下線與客觀下線。
創(chuàng)新互聯(lián)公司-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價比印臺網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式印臺網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋印臺地區(qū)。費用合理售后完善，10年實體公司更值得信賴。
主觀下線簡單來說就是我這個節(jié)點認為你故障了。
客觀下線則是集群中大多數(shù)節(jié)點認為你故障了。
這些判定與狀態(tài)的同步均通過Gossip協(xié)議PING/PONG來通信。
主觀下線流程
- @1 定時向集群中其他節(jié)點發(fā)送PING消息
- @2 超過時間（cluster-node-timeout）未收到接受節(jié)點PONG響應(yīng)消息
- @3 認為該接受節(jié)點存在故障，標(biāo)記為主觀下線狀態(tài)pfail
客觀下線流程
- @1 Gossip協(xié)議PING/PONG通信
攜帶集群1/10的其他節(jié)點狀態(tài)
當(dāng)然也包含主觀下線節(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ù)量的二分之一，標(biāo)記客觀下線
向集群廣播一條fail消息（標(biāo)記客觀下線立即生效、故障從節(jié)點發(fā)起故障轉(zhuǎn)移流程）
二、Redis集群模式的故障轉(zhuǎn)移
Redis集群模式從節(jié)點的作用用于災(zāi)備，主節(jié)點故障時能夠替換頂上去。
- Redis的從節(jié)點當(dāng)然也不例外。
- 多個從節(jié)點誰去替換主節(jié)點？
選舉邏輯以及選舉失效是怎么樣的？
故障轉(zhuǎn)移流程
從節(jié)點中復(fù)制的偏移量越大，替換主節(jié)點的優(yōu)先級越高。
從節(jié)點獲得持有槽的主節(jié)點一半以上的選票，可替換為主節(jié)點。
從節(jié)點向集群廣播PONG消息，通知該變更。
三、常見緩存代理架構(gòu)方案簡述
Redis的集群模式客戶端直連集群，不需要額外的組件，運維難度較低。
由于集群中每個實例都需要保存路由信息，彼此不斷傳播通信更新，也造成通信成本進而影響集群規(guī)模。
Redis的集群模式也會造成客戶端需要重定向，帶來復(fù)雜性。
因此，緩存代理模式可以解決這種復(fù)雜性，當(dāng)然組件也會增多。
客服端：兼容RESP協(xié)議的輕量級客戶端。
集群代理：負責(zé)域客戶端建立連接，以及轉(zhuǎn)發(fā)請求到對應(yīng)的槽位和實例節(jié)點。
元數(shù)據(jù)中心：主要負責(zé)存儲槽位與實例對應(yīng)路由信息以及健康檢查心跳探測。
集群模式一：集群部署主從架構(gòu)，需要元數(shù)中心負責(zé)心跳的健康監(jiān)測，主從節(jié)點的HA，當(dāng)主節(jié)點故障切換從節(jié)點接管。
集群模式二：集群部署Raft組，不需要額外的HA心跳監(jiān)測，集群自閉環(huán)，三個節(jié)點一組成本較高。
模式一
模式二
兼容RESP協(xié)議的輕量級客戶端與代理建立長鏈接。
發(fā)送讀寫請求到代理層，代理根據(jù)路由規(guī)則將key路由到對應(yīng)集群的槽位。
管理平臺可對元數(shù)據(jù)信息、槽位分配、代理以及集群部署運維等進行管理。
可視化白屏化對整個集群的監(jiān)控、告警、大key等水位監(jiān)控告警。
新聞名稱：為什么代理架構(gòu)常作為緩存實現(xiàn)方案
文章路徑：http://fisionsoft.com.cn/article/djpihje.html
