Redis Sentinel 哨兵模式
1.網絡架構
網絡結構以下,經過Sentinel監控Master和Slave服務器:html

2.配置啓動
配置文件以下:redis
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 也須要集羣化,以確保:segmentfault
- 某個/些 Sentinel節點掛了,仍然能夠實現Redis主從切換;
- Redis客戶端能夠經過任意一個Sentinel讀取/寫入信息。
啓動Sentinel:服務器
redis-sentinel /path/to/sentinel.conf
啓動後,經過Sentinel的自動識別,配置文件中會自動加上已識別的Redis集羣節點和Sentinel集羣節點。網絡
3.實現流程
- Sentinel集羣經過配置文件發現master,啓動時會監控master;
- 向master發送info命令,獲取其全部slave節點;
- Sentinel集羣向Redis主從服務器發送hello信息(心跳),包括Sentinel自己的ip、端口、id等內容,以此來向其餘Sentinel宣告本身的存在;
- Sentinel集羣經過訂閱接收其餘Sentinel發送的hello信息,以此來發現監視同一個主服務器的其餘Sentinel;集羣之間會互相建立命令鏈接用於通訊,由於已經有主從服務器做爲發送和接收hello信息的中介,Sentinel之間不會建立訂閱鏈接;
- Sentinel集羣使用ping命令來檢測實例的狀態,若是在指定的時間內(down-after-milliseconds)沒有回覆或則返回錯誤的回覆,那麼該實例被判爲下線;
- 當failover主備切換被觸發後,並不會立刻進行,還須要Sentinel中的大多數sentinel受權後才能夠進行failover,即進行failover的Sentinel會去得到指定quorum個的Sentinel的受權,成功後進入ODOWN狀態。如在5個Sentinel中配置了2個quorum,等到2個Sentinel認爲master死了就執行failover。
- Sentinel向選爲master的slave發送 SLAVEOF NO ONE 命令,選擇slave的條件是Sentinel首先會根據slaves的優先級來進行排序,優先級越小排名越靠前。若是優先級相同,則查看複製的下標,哪一個從master接收的複製數據多,哪一個就靠前。若是優先級和下標都相同,就選擇進程ID較小的。
- 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。異步
故障轉移過程spa
領導者Sentinel須要將一個salve提高爲master,此slave必須爲狀態良好,不能處於SDOWN/ODOWN狀態。code
- 「+failover-triggered」: Leader開始進行failover,此後緊跟着「+failover-state-wait-start」,wait數秒。
- 「+failover-state-select-slave」: Leader開始查找合適的slave
- 「+selected-slave」: 已經找到合適的slave
- 「+failover-state-sen-slaveof-noone」: Leader向slave發送「slaveof no one」指令,此時slave已經完成角色轉換,此slave即爲master
- 「+failover-state-wait-promotition」: 等待其餘sentinel確認slave
- 「+promoted-slave」:確認成功
- 「+failover-state-reconf-slaves」: 開始對slaves進行reconfig操做
- 「+slave-reconf-sent」:向指定的slave發送「slaveof」指令,告知此slave跟隨新的master
- 「+slave-reconf-inprog」: 此slave正在執行slaveof + SYNC過程,如過slave收到「+slave-reconf-sent」以後將會執行slaveof操做。
- 「+slave-reconf-done」: 此slave同步完成,此後leader能夠繼續下一個slave的reconfig操做。循環 step 7
- 「+failover-end」: 故障轉移結束
- 「+switch-master」:故障轉移成功後,各個sentinel實例開始監控新的master。
5.增長和刪除節點
Sentinel會經過PUB/SUB自動識別新增節點。htm
刪除流程:
- 中止所要刪除的sentinel
- 發送一個SENTINEL RESET 命令給全部其它的sentinel實例,若是你想要重置指定master上面的sentinel,只須要把號改成特定的名字,注意,須要一個接一個發,每次發送的間隔不低於30秒(down-after-milliseconds);
- 檢查一下全部的sentinels是否都有一致的當前sentinel數;
參考資料:
https://www.cnblogs.com/zhouj...
http://www.cnblogs.com/zhouji...
https://segmentfault.com/u/be...