Redis Sentinel 哨兵模式

Redis Sentinel 哨兵模式

1.網絡架構

網絡結構以下，經過Sentinel監控Master和Slave服務器：

2.配置啓動

配置文件以下：

vi /etc/redis-sentinel.conf

port 26379     
dir "/tmp"
logfile "/var/log/redis/sentinel_20086.log"

# 進程守護
daemonize yes

# 格式：sentinel <option_name> <master_name> <option_value>
# 最後的一個2表明在sentinel集羣中，多少個節點認爲master死了，才能真正認爲該master不可用
sentinel monitor T1 127.0.0.1 6379 2  

# sentinel會向master發送心跳確認存活
# 若是master在「必定時間範圍」內不迴應PONG 或者是回覆了一個錯誤消息
# 那麼這個sentinel會主觀地認爲這個master已經不可用了
# (subjectively down, 也簡稱爲SDOWN)。
# down-after-milliseconds 用來指定這個「必定時間範圍」，單位是毫秒，默認30秒。
sentinel down-after-milliseconds T1 15000

# failover過時時間。
# 當failover開始後，在此時間內仍然沒有觸發任何failover操做，當前sentinel將會認爲這次failoer失敗。
# 默認180秒，即3分鐘。
sentinel failover-timeout T1 120000

# 在發生failover時，這個選項指定了最多能夠有多少個slave同時對新的master進行同步。
# 這個數字越小，完成failover所需的時間就越長；
# 這個數字越大，就意味着越多的slave由於replication而不可用。
# 能夠經過將這個值設爲 1 來保證每次只有一個slave處於不能處理命令請求的狀態。
sentinel parallel-syncs T1 1

# sentinel 鏈接密碼驗證
# sentinel auth-pass <master_name> xxxxx

# 發生切換以後執行的一個自定義腳本
# sentinel notification-script <master-name> <script-path>
# sentinel client-reconfig-script <master-name> <script-path>

Sentinel 也須要集羣化，以確保：

1. 某個/些 Sentinel節點掛了，仍然能夠實現Redis主從切換；
2. Redis客戶端能夠經過任意一個Sentinel讀取/寫入信息。

啓動Sentinel：

redis-sentinel /path/to/sentinel.conf

啓動後，經過Sentinel的自動識別，配置文件中會自動加上已識別的Redis集羣節點和Sentinel集羣節點。

3.實現流程

1. Sentinel集羣經過配置文件發現master，啓動時會監控master；
2. 向master發送info命令，獲取其全部slave節點；
3. Sentinel集羣向Redis主從服務器發送hello信息（心跳），包括Sentinel自己的ip、端口、id等內容，以此來向其餘Sentinel宣告本身的存在；
4. Sentinel集羣經過訂閱接收其餘Sentinel發送的hello信息，以此來發現監視同一個主服務器的其餘Sentinel；集羣之間會互相建立命令鏈接用於通訊，由於已經有主從服務器做爲發送和接收hello信息的中介，Sentinel之間不會建立訂閱鏈接；
5. Sentinel集羣使用ping命令來檢測實例的狀態，若是在指定的時間內（down-after-milliseconds）沒有回覆或則返回錯誤的回覆，那麼該實例被判爲下線；
6. 當failover主備切換被觸發後，並不會立刻進行，還須要Sentinel中的大多數sentinel受權後才能夠進行failover，即進行failover的Sentinel會去得到指定quorum個的Sentinel的受權，成功後進入ODOWN狀態。如在5個Sentinel中配置了2個quorum，等到2個Sentinel認爲master死了就執行failover。
7. Sentinel向選爲master的slave發送 SLAVEOF NO ONE 命令，選擇slave的條件是Sentinel首先會根據slaves的優先級來進行排序，優先級越小排名越靠前。若是優先級相同，則查看複製的下標，哪一個從master接收的複製數據多，哪一個就靠前。若是優先級和下標都相同，就選擇進程ID較小的。
8. Sentinel被受權後，它將會得到宕掉的master的一份最新配置版本號(config-epoch)，當failover執行結束之後，這個版本號將會被用於最新的配置，經過廣播形式通知其它sentinel，其它的sentinel則更新對應master的配置。

注意：
由於redis採用的是異步複製，沒有辦法避免數據的丟失。
能夠在redis.conf經過如下配置來使得數據不會丟失：

// master最少得有多少個健康的slave存活才能執行寫命令 
min-slaves-to-write 1
// 延遲小於min-slaves-max-lag秒的slave才認爲是健康的slave
min-slaves-max-lag 10

當全部Slave都不符合條件時，master將中止寫入。

4.故障轉移

發生故障轉移時，須要進行領導者選舉。

• sentinel首先會根據slaves的優先級來進行排序，優先級越小排名越靠前；
• 若是優先級相同，則查看複製的下標，哪一個從master接收的複製數據多，哪一個就靠前；
• 若是優先級和下標都相同，就選擇RunID較小的那個；

若是一個redis的slave優先級配置爲0，那麼它將永遠不會被選爲master。

故障轉移過程

領導者Sentinel須要將一個salve提高爲master，此slave必須爲狀態良好，不能處於SDOWN/ODOWN狀態。

1. 「+failover-triggered」: Leader開始進行failover，此後緊跟着「+failover-state-wait-start」，wait數秒。
2. 「+failover-state-select-slave」: Leader開始查找合適的slave
3. 「+selected-slave」: 已經找到合適的slave
4. 「+failover-state-sen-slaveof-noone」: Leader向slave發送「slaveof no one」指令，此時slave已經完成角色轉換，此slave即爲master
5. 「+failover-state-wait-promotition」: 等待其餘sentinel確認slave
6. 「+promoted-slave」：確認成功
7. 「+failover-state-reconf-slaves」: 開始對slaves進行reconfig操做
8. 「+slave-reconf-sent」:向指定的slave發送「slaveof」指令，告知此slave跟隨新的master
9. 「+slave-reconf-inprog」: 此slave正在執行slaveof + SYNC過程，如過slave收到「+slave-reconf-sent」以後將會執行slaveof操做。
10. 「+slave-reconf-done」: 此slave同步完成，此後leader能夠繼續下一個slave的reconfig操做。循環 step 7
11. 「+failover-end」: 故障轉移結束
12. 「+switch-master」：故障轉移成功後，各個sentinel實例開始監控新的master。

5.增長和刪除節點

Sentinel會經過PUB/SUB自動識別新增節點。

刪除流程：

1. 中止所要刪除的sentinel
2. 發送一個SENTINEL RESET 命令給全部其它的sentinel實例，若是你想要重置指定master上面的sentinel，只須要把號改成特定的名字，注意，須要一個接一個發，每次發送的間隔不低於30秒（down-after-milliseconds）；
3. 檢查一下全部的sentinels是否都有一致的當前sentinel數；

---

參考資料：
https://www.cnblogs.com/zhouj...
http://www.cnblogs.com/zhouji...
https://segmentfault.com/u/be...