阿肝正傳之Redis哨兵機制(一)

pikalu發表於2020-11-19

前言

Redis主從同步是提升了可用性,從庫掛了,還有多個從庫可以使用。但是如果主庫掛了,該怎麼辦呢?

這就要提到哨兵機制了。在Redis主從叢集中,哨兵機制是實現主從庫自動切換的關鍵機制,有效的解決了主從複製模式下故障轉移的問題。

哨兵機制的基本流程

哨兵機制就是一個執行在特殊模式下的Redis程式,主從庫例項執行的同時,它在執行。

哨兵主要負責的三個任務:監控、選主和通知。

監控

哨兵在執行時,週期性的會給主庫和從庫傳送PING命令,對應的主庫或者從庫沒有在規定時間內響應,則會標記為“下線狀態”。

自動切換

主庫掛了之後,哨兵需要從多個從庫裡,按照一定規則,選舉一個從庫為主庫。

通知

哨兵會將新的主庫資訊傳送給其他從庫,讓他們執行replicaof命令,和新主庫建立連線,並進行資料複製。

同時新的主庫資訊會通知給客戶端,讓他們將新的請求傳送到新主庫上。

主觀下線和客觀下線

上面我們提到,哨兵程式會通過PING命令檢測它和主從庫網路的連線狀況,用來判斷示例的狀態。

如果檢測的是從庫,簡單的標記為“主觀下線”即可,因為從庫下線影響不大,叢集對外服務不會間斷。

如果檢測的是主庫,則不能輕易標記為“主觀下線”。因為哨兵存在誤判的情況,主庫其實沒有故障。但是一旦開啟了主從切換,後續的選主和通知操作都會帶來額外的計算和通訊開銷。

那麼如何減少誤判呢?

通常會採用多例項組成的叢集模式進行部署,也就是哨兵叢集。

引入多個哨兵例項一起判斷,可以避免單個例項因自身網路狀態不好,而導致誤判的情況。當大多數的哨兵例項都判斷主庫為“主觀下線”時,主庫才會被標記為“客觀下線”。遵循原則“少數服從多數”。

如何選擇新主庫?

這裡我們先來看一個流程圖:

Redis哨兵選主篩選評分

主要的過程就是篩選和打分。

篩選

保證所選擇的從庫仍然線上執行,其次還要判斷之前的網路連線狀態。如何判斷呢?有個配置項down-after-milliseconds,是主從庫斷連的最大連線超時時間。在這個時間內,主從庫還沒連線上,我們可以認為是斷連。如果斷連次數超過10次,則認為這個庫的網路狀況不好,不適合做新主庫。

打分

三輪打分,只要某一輪某個庫的得分最高,就選定為主庫;如果沒有,則進行下一輪。

優先順序最高的從庫得分最高

手動配置slave-priority,給不同的從庫設定不同的優先順序。根據配置,我們可以給配置更好的從庫設定高優先順序。

和舊主庫同步最近的那個從庫作為主庫

主庫會用master_repl_offset記錄當前最新的寫操作在repl_backlog_buffer緩衝區中的位置,從庫會用slave_repl_offset記錄從庫當前複製的位置,兩者距離最近則評分高。

ID號小的從庫得分高

每個示例都會有個ID,這裡類似於從庫的編號。

Redis在選主庫時,有個預設的規定:在優先順序和複製進度都一樣的情況下,ID最小的庫得分最高。

通過以上三步,可以選出新主庫。

其他

原文連結:tsmliyun.github.io/redis/%E9%98%BF...

參考資料

極客時間《Redis核心技術與實戰》

本作品採用《CC 協議》,轉載必須註明作者和本文連結
不積跬步,無以至千里;不積小流,無以成江海

相關文章