sdown和odown轉換機制
sdown和odown兩種失敗狀態redis
sdown是主觀宕機，就一個哨兵若是本身以爲一個master宕機了，那麼就是主觀宕機算法
odown是客觀宕機，若是quorum數量的哨兵都以爲一個master宕機了，那麼就是客觀宕機spa
sdown達成的條件很簡單，若是一個哨兵ping一個master，超過了is-master-down-after-milliseconds指定的毫秒數以後，就主觀認爲master宕機排序
sdown到odown轉換的條件很簡單，若是一個哨兵在指定時間內，收到了quorum指定數量的其餘哨兵也認爲那個master是sdown了，那麼就認爲是odown了，客觀認爲master宕機ip
哨兵集羣的自動發現機制
哨兵互相之間的發現，是經過redis的pub/sub系統實現的，每一個哨兵都會往__sentinel__:hello這個channel裏發送一個消息，這時候全部其餘哨兵均可以消費到這個消息，並感知到其餘的哨兵的存在同步
每隔兩秒鐘，每一個哨兵都會往本身監控的某個master+slaves對應的__sentinel__:hello channel裏發送一個消息，內容是本身的host、ip和runid還有對這個master的監控配置it
每一個哨兵也會去監聽本身監控的每一個master+slaves對應的__sentinel__:hello channel，而後去感知到一樣在監聽這個master+slaves的其餘哨兵的存在io
每一個哨兵還會跟其餘哨兵交換對master的監控配置，互相進行監控配置的同步ast
slave配置的自動糾正class
哨兵會負責自動糾正slave的一些配置，好比slave若是要成爲潛在的master候選人，哨兵會確保slave在複製現有master的數據; 若是slave鏈接到了一個錯誤的master上，好比故障轉移以後，那麼哨兵會確保它們鏈接到正確的master上
slave->master選舉算法
若是一個master被認爲odown了，並且majority哨兵都容許了主備切換，那麼某個哨兵就會執行主備切換操做，此時首先要選舉一個slave來
會考慮slave的一些信息
（1）跟master斷開鏈接的時長
（2）slave優先級
（3）複製offset
（4）run id
若是一個slave跟master斷開鏈接已經超過了down-after-milliseconds的10倍，外加master宕機的時長，那麼slave就被認爲不適合選舉爲master
(down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state
接下來會對slave進行排序
（1）按照slave優先級進行排序，slave priority越低，優先級就越高
（2）若是slave priority相同，那麼看replica offset，哪一個slave複製了越多的數據，offset越靠後，優先級就越高
（3）若是上面兩個條件都相同，那麼選擇一個run id比較小的那個slave
quorum和majority
每次一個哨兵要作主備切換，首先須要quorum數量的哨兵認爲odown，而後選舉出一個哨兵來作切換，這個哨兵還得獲得majority哨兵的受權，才能正式執行切換
若是quorum < majority，好比5個哨兵，majority就是3，quorum設置爲2，那麼就3個哨兵受權就能夠執行切換
可是若是quorum >= majority，那麼必須quorum數量的哨兵都受權，好比5個哨兵，quorum是5，那麼必須5個哨兵都贊成受權，才能執行切換
configuration epoch
哨兵會對一套redis master+slave進行監控，有相應的監控的配置
執行切換的那個哨兵，會從要切換到的新master（salve->master）那裏獲得一個configuration epoch，這就是一個version號，每次切換的version號都必須是惟一的
若是第一個選舉出的哨兵切換失敗了，那麼其餘哨兵，會等待failover-timeout時間，而後接替繼續執行切換，此時會從新獲取一個新的configuration epoch，做爲新的version號
configuraiton傳播
哨兵完成切換以後，會在本身本地更新生成最新的master配置，而後同步給其餘的哨兵，就是經過以前說的pub/sub消息機制
這裏以前的version號就很重要了，由於各類消息都是經過一個channel去發佈和監聽的，因此一個哨兵完成一次新的切換以後，新的master配置是跟着新的version號的
其餘的哨兵都是根據版本號的大小來更新本身的master配置的