Redis的七個核心機制底層原理

1、S_DOWN和O_DOWN

  S_DOWN和O_DOWN兩種宕機狀態

（1）、S_DOWN是主觀宕機，就一個哨兵若是本身以爲一個master宕機了，那麼就是主觀宕機<br> sdown達成的條件很簡單，若是一個哨兵ping一個master，超過了is-master-down-after-milliseconds指定的毫秒數以後，就主觀認爲master宕機<br>

# 語法：sentinel down-after-milliseconds <master-name> <milliseconds>
# Number of milliseconds the master (or any attached replica or sentinel) should
# be unreachable (as in, not acceptable reply to PING, continuously, for the
# specified period) in order to consider it in S_DOWN state (Subjectively Down).
# 意思是任何從節點或者哨兵在指定的時間內，不能ping通主機就被認爲成S_DOWN

（2）、O_DOWN是客觀宕機，若是quorum數量的哨兵都以爲一個master宕機了，那麼就是客觀宕機

 注意：S_DOWN到O_DOWN轉換的條件很簡單，若是一個哨兵在指定時間內，收到了quorum指定數量的其餘哨兵也認爲那個master是S_DOWN了，那麼就認爲是O_DOWN了

# 語法：sentinel monitor <master-name> <ip> <redis-port> <quorum>
# Tells Sentinel to monitor this master, and to consider it in O_DOWN
# (Objectively Down) state only if at least <quorum> sentinels agree.
# 意思是：告訴Sentinel監視這個master，若是至少quorum 數量的哨兵贊成的話就變成了
# 客觀宕機

2、哨兵集羣的自動發現機制

一、哨兵互相之間的發現，是經過redis的pub/sub系統實現的，每一個哨兵都會往sentinel:hello這個channel裏發送一個消息，這時候全部其餘哨兵均可以消費到這個消息，並感知到其餘的哨兵的存在。
二、每隔兩秒鐘，每一個哨兵都會往本身監控的某個master+slaves對應的sentinel:hello channel裏發送一個消息，內容是本身的host、ip和runid還有對這個master的監控配置，每一個哨兵也會去監聽本身監控的每一個master+slaves對應的sentinel:hello channel，而後去感知到一樣在監聽這個master+slaves的其餘哨兵的存在。 
三、每一個哨兵還會跟其餘哨兵交換對master的監控配置，互相進行監控配置的同步。

3、slave配置的自動糾正

  哨兵會負責自動糾正slave的一些配置，好比slave若是要成爲潛在的master候選人，哨兵會確保slave在複製現有master的數據; 若是slave鏈接到了一個錯誤的master上，好比故障轉移以後，那麼哨兵會確保它們鏈接到正確的master上

4、從機變主機的選舉算法

若是一個master被認爲O_DOWN了，並且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優先級進行排序，replica-priority越低，優先級就越高，下面的英文就是這個的解釋：

# The replica priority is an integer number published by Redis in the INFO output.
# It is used by Redis Sentinel in order to select a replica to promote into a
# master if the master is no longer working correctly.
#
# A replica with a low priority number is considered better for promotion, so
# for instance if there are three replicas with priority 10, 100, 25 Sentinel will
# pick the one with priority 10, that is the lowest.
#
# However a special priority of 0 marks the replica as not able to perform the
# role of master, so a replica with priority of 0 will never be selected by
# Redis Sentinel for promotion.
#
# By default the priority is 100.
replica-priority 100

（2）若是slave priority相同，那麼看replica offset，哪一個slave複製了越多的數據，offset越靠後，優先級就越高
（3）若是上面兩個條件都相同，那麼選擇一個run id比較小的那個slave

5、quorum和majority

一、每次一個哨兵要作主備切換，首先須要quorum數量的哨兵認爲O_DOWN，而後選舉出一個哨兵來作切換，這個哨兵還得獲得majority哨兵的受權，才能正式執行切換 
二、若是quorum < majority，好比5個哨兵，majority就是3，quorum設置爲2，那麼就3個哨兵受權就能夠執行切換,可是若是quorum >= majority，那麼必須quorum數量的哨兵都受權，好比5個哨兵，quorum是5，那麼必須5個哨兵都贊成受權，才能執行切換

6、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配置的