redis並無提供自動master選舉功能,redis
- 而是須要藉助一個哨兵來進行監控
哨兵的做用就是監控Redis系統的運行情況,算法
- 它的功能包括兩個
- 監控master和slave是否正常運行
- master出現故障時自動將slave數據庫升級爲master
- 哨兵是一個獨立的進程,使用哨兵後的架構圖
- 爲了解決master選舉問題,又引出了一個單點問題,
- 也就是哨兵的可用性如何解決
- 在一個一主多從的Redis系統中,
- 可使用多個哨兵進行監控任務以保證系統足夠穩定
- 時哨兵不只會監控master和slave,
- 同時還會互相監控;
- 這種方式稱爲哨兵集羣,
- 哨兵集羣須要解決
- 故障發現、和master決策的協商機制問題
- 哨兵集羣須要解決
- 爲了解決master選舉問題,又引出了一個單點問題,
- sentinel之間的相互感知
- sentinel節點之間會由於共同監視同一個master從而產生了關聯,
- 一個新加入的sentinel節點須要和其餘監視相同master節點的sentinel相互感知
- 須要相互感知的sentinel都向他們共同監視的master節點訂閱
- channel:sentinel:hello
- 新加入的sentinel節點向這個channel發佈一條消息,
- 包含本身自己的信息,
- 這樣訂閱了這個channel的sentinel就能夠發現這個新的sentinel
- 新加入的sentinel和其餘sentinel節點創建長鏈接
- 須要相互感知的sentinel都向他們共同監視的master節點訂閱
- 一個新加入的sentinel節點須要和其餘監視相同master節點的sentinel相互感知
- sentinel節點之間會由於共同監視同一個master從而產生了關聯,
master的故障發現數據庫
- sentinel節點會按期向master節點發送心跳包來判斷存活狀態,
- 一旦master節點沒有正確響應,
- sentinel會把master設置爲「主觀不可用狀態」,
- 而後它會把「主觀不可用」發送給其餘全部的sentinel節點去確認,
- 當確認的sentinel節點數大於>quorum時,
- 則會認爲master是「客觀不可用」,
- 接着就開始進入選舉新的master流程;
- 那誰來決策選擇哪一個節點做爲maste呢?
- 這裏用到了一致性算法Raft算法(該算法用於哨兵的Master選舉)、它和Paxos算法相似,都是分佈式一致性算法。
- redis的master選舉的時候會考慮slave的一些信息:
- 跟master斷開鏈接的時長
- slave優先級
- 複製offset
- run id
- redis的master選舉的時候會考慮slave的一些信息:
- 可是它比Paxos算法要更容易理解;
- Raft和Paxos算法同樣,也是基於投票算法,
- 只要保證過半數節點經過提議便可;
- 這裏用到了一致性算法Raft算法(該算法用於哨兵的Master選舉)、它和Paxos算法相似,都是分佈式一致性算法。
- 那誰來決策選擇哪一個節點做爲maste呢?
配置實現服務器
- 在其中任意一臺服務器上建立一個sentinel.conf文件,文件內容
- sentinel monitor name ip port quorum
- 其中name表示要監控的master的名字,這個名字是本身定義。
- ip和port表示master的ip和端口號。
- 最後一個1表示最低經過票數,
- 也就是說至少須要幾個哨兵節點統一才能夠,
- sentinel monitor mymaster 192.168.11.131 6379 1
- sentinel down-after-milliseconds mymaster 5000
- --表示若是5s內mymaster沒響應,就認爲SDOWN
- sentinel failover-timeout mymaster 15000
- --表示若是15秒後,mysater仍沒活過來,
- 則啓動failover,從剩下的slave中選一個升級爲master
- sentinel monitor name ip port quorum
- 兩種方式啓動哨兵
- redis-sentinel sentinel.conf
- redis-server /path/to/sentinel.conf --sentinel
- 哨兵監控一個系統時,
- 只須要配置監控master便可,
- 哨兵會自動發現全部slave;
- 這時候,咱們把master關閉,等待指定時間後(默認是30秒),會自動進行切換
- +sdown表示哨兵主觀認爲master已經中止服務了,
- +odown表示哨兵客觀認爲master中止服務了。
- 接着哨兵開始進行故障恢復,
- 挑選一個slave升級爲master
- +try-failover表示哨兵開始進行故障恢復
- +failover-end 表示哨兵完成故障恢復
- +slave表示列出新的master和slave服務器,
- 咱們仍然能夠看到已經停掉的master,
- 哨兵並無清楚已中止的服務的實例,
- 這是由於已經中止的服務器有可能會在某個時間進行恢復,
- 恢復之後會以slave角色加入到整個集羣中