本篇重點
哨兵機制的“監控”、“選主”、“通知”
0.0 背景
主從庫采取“讀寫分離”模式，主庫掛了，Redis讀操作可以由從庫執行，但寫操作智能由主庫執行后同步給從庫，一旦主庫掛了，寫服務終端，從庫無法進行數據同步
解決方案：運行新主庫：即從從庫中選舉一個從庫作為新主庫，這種主庫掛了后從庫選舉新主庫的機制就是Redis哨兵機制
0.1 前言
- 哨兵機制需要考慮的三個問題
- 主庫真的掛了嗎？
- 該選擇哪個庫作為新主庫？
- 怎么把新主庫的相關信息通知給從庫和客戶端？
- 哨兵機制的三個功能
- 監控主庫運行狀態，判斷主庫是否“客觀下線”
- 在主庫“客觀下線”后，選舉新主庫
- 將新主庫信息通知給從庫和客戶端
- 哨兵集群
- 哨兵需要監控主從庫的狀態並在主庫下線后及時選舉從庫，因此需要多個哨兵組成哨兵集群
- 這篇先引出哨兵集群的概念，具體集群中的一些操作見下篇[鏈接]
1.1 監控
判斷主庫是否下線的兩個標准：主觀下線、客觀下線
哨兵會定期給主庫（和其他從庫）執行ping判斷對方是否在線
- 主觀下線
- 哨兵A ——> 主庫 ： ping； 若主庫響應超時，則哨兵A判定主庫主觀下線
- 主觀下線存在誤判情況：主庫在線，但由於網絡擁塞/Redis集群網絡壓力較大等導致主庫沒有及時響應ping
- 客觀下線
- 哨兵集群 ——> 主庫 ：ping；每個哨兵都將自己ping主庫的結果拿出來
- 若判定主庫狀態為“（主觀）下線”的哨兵數 > 哨兵集群總數一半，即判斷主庫客觀下線；“少數服從多數”
1.2 選主
步驟： “篩選” + “打分” 、 “一定的篩選條件”、“一定的打分規則”
- “篩選”：篩選出從庫狀態良好的那些參與選舉。篩選條件參考如下
- 從庫在線
- 從庫網絡連接狀態良好（需保證在一段時間內該從庫與主庫的網絡斷連次數在一定閾值內）
可通過
down-after-miliseconds設定主從庫網絡斷連的最大連接超時時間
例子：設置down-after-milliseconds * 10，則表示down-after-milliseconds 毫秒內，主從節點都沒有通過網絡聯系上，認為主從節點斷連。如果發生斷連的次數超過了 10 次，就說明這個從庫的網絡狀況不好，不適合作為新主庫。
- “打分”：依次比較從庫的優先級、復制進度、ID號，選出最適合的
- 從庫優先級： 通過
slave_priority設置， 優先級越高，得分越高，優先級最高且唯一的作為新主庫。（若這一輪沒有選舉出來，則進行下一輪——從庫復制進度的選舉） - 從庫復制進度：通過比較
master_repl_offset和slave_repl_offset，選出與主庫同步程度最接近的從庫作為新主庫。（若這一輪沒有選舉出來，則進行最后一輪——從庫ID的選舉） - 從庫ID號：每個從庫都有唯一的ID，在這一輪選取ID號最小的從庫作為新主庫
- 從庫優先級： 通過
1.3 通知
新主庫選舉出來后，需要通知給其他從庫：以后從新主庫同步數據；通知給客戶端：與新主庫進行寫操作
- 通知給其他從庫
- 其他從庫需要執行
replicaof與新主庫建立“主-從”關系並進行“數據同步”
- 其他從庫需要執行
- 通知給客戶端
Q&A
- 主從庫切換的時間段內，客戶端能否正常請求操作？
- 若想應用程序不感知服務中斷，還需要哨兵或Client做什么？
圖片來源於極客時間專欄《Redis核心技術與實戰》