redis 系列24 哨兵Sentinel (中)
四. 檢測下線狀態
對於Redis的Sentinel中關於下線有兩個不同的概念：(1)主觀下線(Subjectively Down， 簡稱 Sdown) 指的是單個 Sentinel 實例對服務器做出的下線判斷，此時不會進行故障轉移。(2) 客觀下線（Objectively Down， 簡稱 Odown）指的是多個 Sentinel 實例在對同一個服務器做出 Sdown 判斷，此時目標sentinel會對主服務器進行故障轉移。本篇具體詳細介紹。
4.1 檢測主觀下線狀態
默認情況下，Sentinel會以每秒一次的頻率向所有與它創建命令連接的實例(包括主、從、其他sentinel在內)發送ping命令，並通過實例返回的ping命令回復來判斷實例是否在線。
(1) 有效回復: 實例返回 +pong 、 -loading、 -masterdown三種回復的其中一種。
(2)無效回復: 實例返回上面三種回復之處的其它回復，或者在指定時限內沒有返回任何回復。在Sentinel.conf配置文件中的down-after-milliseconds選項指定了Sentinel判斷實例進入主觀下線所需的時間長度。
4.1.1主觀下線時長選項的作用範圍
用戶設置down-after-milliseconds選項的值，不僅會被sentinel用來判斷主服務器的主觀下線狀態，還會被用於判斷主服務器下的所有從服務器，以及同樣監視主服務器的其他sentinel的主觀下線狀態。
-- 例如用戶向sentinel設置以了下配置： sentinel monitor master 127.0.0.1 6379 2 sentinel down-after-milliseconds master 50000
這裏的master是主服務器的名稱， 端口默認6379 ，2代表sentinel集群中有2個sentinel認為master 狀態下線時，才能真正認為該master已經不可用了(也就是客觀下線，下面會講)。這50000毫秒不僅會成為sentinel判斷master進入主觀下線的標準，還會判斷所有從庫、其它sentinel進入主觀下線的標準
4.1.2 多個sentinel設置的主觀下線時長可能不同
對於多個sentinel共同監視同一個主服務器時，這些sentinle在配置文件sentinle.conf中所設置的down-after-milliseconds值也可能不同，因此當一個sentinel將主服務器判斷為主觀下線時，其它sentinel可能仍然會認為主服務器處於在線狀態。只有全部的sentine都判斷進入了主觀下線狀態時，才會認為主master進入了主觀下線狀態。
4.2 檢查客觀下線狀態
當sentinel將一個主服務器判斷為主觀下線之後，為了確認這個主服務器是否真要下線，會向同樣監視這一主服務器的其它sentinel進行詢問，其它sentinel回復已下線之後，sentinel就會將主服務器從主觀判定為客觀下線，並對主服務器執行故障轉移操作。客觀下線條件只適用於主服務器。
客觀判斷是：sentinel向其它sentinel發送sentinel is-master-down-by-addr命令進行互相交流之後，得出主服務器下線判斷。 只要一個 Sentinel 發現某個主服務器進入了客觀下線狀態， 這個 Sentinel 就可能會被其他 Sentinel 推選出， 並對失效的主服務器執行自動故障遷移操作。
4.2.1 is-master-down-by-addr命令用來判斷是否客觀下線
命令格式：sentinel is-master-down-by-addr ip port current runid
分別代表主觀下線的主服務器ip址址，端口號, sentinel當前的配置紀元用於選舉領頭羊sentinel, runid可以是*或者sentinel的運行ID。
--例如一個sentinel向其它sentinel發送以下命令： sentinel is-master-down-by-addr 127.0.0.1 6379 0 *
最後一個參數：*代表命令僅僅用於檢測主服務器客觀下線狀態。而sentinel的運行ID則用於選舉領頭羊。當接收的sentinel收到其它sentinel回復的命令時，會取出命令中包含的參數，來檢查主服務器是否已下線，然後向源sentinel返回一條信息。該信息包括三個參數：
(1) down_state: 檢查主服務器的結果，1代表已下線，2代表未下線。
(2) leader_runid: 如果是* 用於檢測主服務器下線狀態。如果是runid則是局部領頭sentinel的運行ID，用於選舉領頭sentinel。
(3) leader_epoch: 目標sentinel的局部領頭sentinel的配置紀元。
例如返回: 1 * 1 。說明其它sentinel也同意主服務器下線。接收sentinel將統計其他sentinel同意主服務器下線的數量，當這一數量達到配置指定的數量時，就會客觀下線，進行故障轉移。
例如: sentinel monitor master 127.0.0.1 6379 2 配置是指包括當前sentinel在內，只要總共有兩個sentinel 服務認為主服務器已經進入下線狀態，那麽當前sentinel就將主服務器判斷為客觀下線。
五. 選舉領頭sentinel
當一個主服務器被判斷為客觀下線時，監視這個下線主服務器的各個sentinel會進行協商，選擇出一個領頭sentinel，並由領頭sentinel對下線主服務器執行故障轉移操作，關於Redis選舉領頭sentinel規則和方法就不在述說，請看"redis設計與實現"書籍。
六.故障轉移
選舉產生領頭sentinel之後，領頭sentinel將對已下線的主服務器執行故障轉移，操作包括三個步驟：
(1) 在已下線的主服務器屬下的所有從服務器中，挑選出一個從服務器，並將其轉換為主服務器。挑選是經過了嚴格的一項一項的過濾(如過濾從庫下線的，5秒內沒有回復領頭sentinel的info命令的，與以下線的主服務器連接斷開超過down-after-milliseconds *10 毫秒的。這些通通都刪除)，之後選出最優的從服務器。向這個從服務器發送slaveof no one命令，將這個從服務器轉換為主服務器。
(2) 讓已下線主服務器屬下的所有從服務器改為復制新的主服務器。領頭sentinel向已下線的主服務和所有從服務器(除了新的主服務)發送slaveof 命令，讓它們復制新的主服務器。
(3) 將已下線的主服務器設置為從服務器。當已下線的主服務器重新上線時，sentinel就會向它發送slaveof命令，讓它成為從服務。
七 sentinel上下二篇原理總結：
對於sentinel的高可用，用了二篇來介紹了sentinel服務、主服務、從服務、其它sentinel服務的原理關系。知識點比較多，下面再總結下：
(1) sentinel只是一個運行在特殊模式下的redis服務器，它使用了和普通模式不同的命令表，以及區別與普通模式下使用的命令不同。
(2) sentinel會讀入指定的配置文件(sentinel.conf)，為每個要監視的主服務器創建相應的實例結構，並創建連向主服務器的命令連接和訂閱連接，其中命令連接用於向主服務器發送命令請求，訂閱連接則用於接收指定頻道的消息。
(3) sentinel通過向主服務器發送info命令來獲得主服務器屬下所有從服務器的地址信息，並為這些從服務器創建相應的實例結構，以及連向這些從服務器的命令連接和訂閱連接。
(4) 一般情況下，sentinel以每10秒一次的頻率向被監視的主服務器和從服務器發送info命令，當主服務器處於下線狀態，或者sentinel正在對主服務器進行故障轉移操作時，sentinel向從服務器發送info命令的頻率會改為1秒一次。
(5)對於監視同一個主服務器和從服務器的多個sentinel來說，它們會以每2秒一次的頻率，通過向被監視的_sentinel_:hello頻道發送消息來向其他sentinel宣告自己的存在。
(6)每個sentinel也會從_sentinel_:hello中頻道中接收其他sentinel發來的信息，並根據這些信息為其他sentinel創建相應的實例結構，以及命令連接。
(7) sentinel只會與主服務器和從服務器創建命令連接和訂閱連接，sentinel與sentinel之間則只創建命令連接。
(8) sentinel以每秒一次的頻率向實例(包括主，從，其它sentinel)發送ping命令，並根據實例對ping命令的回復來判斷實例是否在線，當一個實例在指定的時長中連續向sentinel發送無效回復時，sentinel會將這個實例判斷為主觀下線。
(9)當sentinel將一個主服務器判斷為主觀下線時，它會向同樣的監視這個主服務器的其他sentinel進行詢問，看它們是否同意這個主服務器已經進入主觀下線狀態。
(10)當sentinel收集到足夠多的主觀下線投票之後，它會將主服務器判斷為客觀下線，並發起一次針對主服務器的故障轉移操作。
redis 系列24 哨兵Sentinel (中)