一、sdown和odown轉換機制

sdown和odown是兩種失敗狀態。

（1）sdown是主觀宕機，就一個哨兵如果自己覺得一個master宕機了，那麼就是主觀宕機。

（2）odown是客觀宕機，如果quorum數量的哨兵都覺得一個master宕機了，那麼就是客觀宕機。

（3）sdown達成的條件很簡單，如果一個哨兵ping一個master，超過了is-master-down-after-milliseconds指定的毫秒數之後，就主觀認為master宕機。

（4）sdown到odown轉換的條件很簡單，如果一個哨兵在指定時間內，收到了quorum指定數量的其他哨兵也認為那個master是sdown了，那麼就認為是odown了，客觀認為master宕機。

二、哨兵叢集的自動發現機制

（1）哨兵互相之間的發現是通過redis的pub/sub系統實現的，每個哨兵都會往__sentinel__:hello這個channel裡傳送一個訊息，這時候所有其他哨兵都可以消費到這個訊息，並感知到其他的哨兵的存在。

（2）每隔兩秒鐘，每個哨兵都會往自己監控的某個master+slaves對應的__sentinel__:hello channel裡傳送一個訊息，內容是自己的host、ip和runid還有對這個master的監控配置。

（3）每個哨兵也會去監聽自己監控的每個master+slaves對應的__sentinel__:hello channel，然後去感知到同樣在監聽這個master+slaves的其他哨兵的存在。

（4）每個哨兵還會跟其他哨兵交換對master的監控配置，互相進行監控配置的同步。

三、slave配置的自動糾正

哨兵會負責自動糾正slave的一些配置，比如slave如果要成為潛在的master候選人，哨兵會確保slave在複製現有master的資料。如果slave連線到了一個錯誤的master上，比如故障轉移之後，那麼哨兵會確保它們連線到正確的master上。

四、slave->master選舉演算法

如果一個master被認為odown了，而且majority哨兵都允許了主備切換，那麼某個哨兵就會執行主備切換操作，此時首先要選舉一個slave來，選舉一個slave會考慮如下的一些資訊：

（1）slave跟master斷開連線的時長；
（2）slave優先順序；
（3）複製offset；
（4）run id；

如果一個slave跟master斷開連線已經超過了down-after-milliseconds的10倍，外加master宕機的時長，那麼slave就被認為不適合選舉為master。對於多個符合條件的slave，接下來會對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號。

七、configuration傳播

哨兵完成切換之後，會在自己本地更新生成最新的master配置，然後同步給其他的哨兵，就是通過之前說的pub/sub訊息機制。這裡之前的version號就很重要了，因為各種訊息都是通過一個channel去釋出和監聽的，所以一個哨兵完成一次新的切換之後，新的master配置是跟著新的version號的。其他的哨兵都是根據版本號的大小來更新自己的master配置的。