前言
Redis主從同步是提升了可用性，從庫掛了，還有多個從庫可以使用。但是如果主庫掛了，該怎麼辦呢？
這就要提到哨兵機制了。在Redis主從叢集中，哨兵機制是實現主從庫自動切換的關鍵機制，有效的解決了主從複製模式下故障轉移的問題。
哨兵機制的基本流程
哨兵機制就是一個執行在特殊模式下的Redis程式，主從庫例項執行的同時，它在執行。
哨兵主要負責的三個任務：監控、選主和通知。
監控
哨兵在執行時，週期性的會給主庫和從庫傳送PING命令，對應的主庫或者從庫沒有在規定時間內響應，則會標記為“下線狀態”。
自動切換
主庫掛了之後，哨兵需要從多個從庫裡，按照一定規則，選舉一個從庫為主庫。
通知
哨兵會將新的主庫資訊傳送給其他從庫，讓他們執行replicaof命令，和新主庫建立連線，並進行資料複製。
同時新的主庫資訊會通知給客戶端，讓他們將新的請求傳送到新主庫上。
主觀下線和客觀下線
上面我們提到，哨兵程式會通過PING命令檢測它和主從庫網路的連線狀況，用來判斷示例的狀態。
如果檢測的是從庫，簡單的標記為“主觀下線”即可，因為從庫下線影響不大，叢集對外服務不會間斷。
如果檢測的是主庫，則不能輕易標記為“主觀下線”。因為哨兵存在誤判的情況，主庫其實沒有故障。但是一旦開啟了主從切換，後續的選主和通知操作都會帶來額外的計算和通訊開銷。
那麼如何減少誤判呢？
通常會採用多例項組成的叢集模式進行部署，也就是哨兵叢集。
引入多個哨兵例項一起判斷，可以避免單個例項因自身網路狀態不好，而導致誤判的情況。當大多數的哨兵例項都判斷主庫為“主觀下線”時，主庫才會被標記為“客觀下線”。遵循原則“少數服從多數”。
如何選擇新主庫？
這裡我們先來看一個流程圖：
主要的過程就是篩選和打分。
篩選
保證所選擇的從庫仍然線上執行，其次還要判斷之前的網路連線狀態。如何判斷呢？有個配置項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 協議》，轉載必須註明作者和本文連結