redis哨兵模式
設定的哨兵模式和其他redis伺服器相同，只不過不能做儲存等處理
哨兵也是 Redis 伺服器，只是它與我們平時提到的 Redis 伺服器職能不同，哨兵負責監視普通的 Redis 伺服器，提高一個伺服器叢集的健壯和可靠性。哨兵和普通的 Redis 伺服器所用的是同一套伺服器框架，這包括：網路框架，底層資料結構，訂閱釋出機制等。
· 監控(Monitoring): 哨兵(sentinel) 會不斷地檢查你的Master和Slave是否運作正常。
· 提醒(Notification):當被監控的某個 Redis出現問題時, 哨兵(sentinel) 可以通過 API 向管理員或者其他應用程式傳送通知。
· 自動故障遷移(Automatic failover):當一個Master不能正常工作時，哨兵(sentinel) 會開始一次自動故障遷移操作,它會將失效Master的其中一個Slave升級為新的Master, 並讓失效Master的其他Slave改為複製新的Master; 當客戶端試圖連線失效的Master時,叢集也會向客戶端返回新Master的地址,使得叢集可以使用Master代替失效Master。
哨兵(sentinel) 是一個分散式系統,你可以在一個架構中執行多個哨兵(sentinel) 程序,這些程序使用流言協議(gossipprotocols)來接收關於Master
每個哨兵(sentinel) 會向其它哨兵(sentinel)、master、slave定時傳送訊息,以確認對方是否”活”著,如果發現對方在指定時間(可配置)內未迴應,則暫時認為對方已掛(所謂的”主觀認為宕機” Subjective Down,簡稱sdown).
若“哨兵群”中的多數sentinel,都報告某一master沒響應,系統才認為該master"徹底死亡"(即:客觀上的真正down機,Objective Down,簡稱odown),通過一定的vote
哨兵群中擁有首領
總結了一下選舉哨兵首領的過程：
- 遍歷哨兵表中的所有哨兵，統計每個哨兵的得票情況，注意，得票哨兵的版本號必須和執行故障修復哨兵的配置版本號相同，這樣做是為了確認執行故障修復版本號已經將自己的版本告訴了其他的哨兵。【這裡在畫圖的時候可以說明白，其實低版本號的哨兵是沒有機會進行故障修復的】
- 計算得票最多的哨兵
- 執行故障修復的哨兵自己給得票數最高的哨兵投一票，如果沒有投票結果，則給自己投一票。當然投票的前提還是配置版本號要比自己的高。
- 再次計算得票最多的哨兵
- 滿足兩個條件：得票最多的哨兵的票數必須超過選舉數的一半以上；得票最多的哨兵的票數必須超過主機的法定人數（quorum）。
是一個比較曲折的過程。最終，如果確定當前執行故障修復的哨兵是首領，它則可以進入下一個狀態：SELECT_SLAVE。
SELECT_SLAVE
SELECT_SLAVE 的意圖很明確，因為當前的主機（master）已經掛了，需要重新指定一個主機，候選的伺服器就是當前掛掉主機的所有從機（slave）。
在
sentinelTimer()-»sentinelHandleDictOfRedisInstances()-»sentinelHandleRedisInstance()-»sentinelFailoverStateMachine()-»sentinelFailoverSelectSlave()-»sentinelSelectSlave() 你可以看到詳細的選舉過程。
當前執行故障修復的哨兵會遍歷主機的所有從機，只有足夠健康的從機才能被成為候選主機。足夠健康的條件包括：
- 不能有下面三個標記中的一個：SRI_S_DOWN|SRI_O_DOWN|SRI_DISCONNECTED
- ping 心跳正常
- 優先順序不能為 0（slave->slave_priority）
- INFO 資料不能超時
- 主從連線斷線會時間不能超時
滿足以上條件就有機會成為候選主機，如果經過上面的篩選之後有多臺從機，那麼這些從機會按下面的條件排序：
- 優選選擇優先順序高的從機
- 優先選擇主從複製偏移量高的從機，即從機從主機複製的資料越多
- 優先選擇有 runid 的從機
- 如果上面條件都一樣，那麼將 runid 按字典順序排序
所選用的排序演算法是常用的快排。這是一個比較曲折的過程。如果沒有從機符合要求，譬如最極端的情況，所有從機都跟著掛了，那麼故障修復會失敗；否則最終會確定一個從機成為候選主機。從機可以進入下一個狀態：SLAVEOF_NOONE。