Redis集羣-哨兵機制

redis並無提供自動master選舉功能,redis

  • 而是須要藉助一個哨兵來進行監控

哨兵的做用就是監控Redis系統的運行情況,算法

  • 它的功能包括兩個
    • 監控master和slave是否正常運行
    • master出現故障時自動將slave數據庫升級爲master
  • 哨兵是一個獨立的進程,使用哨兵後的架構圖
    • 爲了解決master選舉問題,又引出了一個單點問題,
      • 也就是哨兵的可用性如何解決
      • 在一個一主多從的Redis系統中,
        • 可使用多個哨兵進行監控任務以保證系統足夠穩定
      • 時哨兵不只會監控master和slave,
        • 同時還會互相監控
      • 這種方式稱爲哨兵集羣
        • 哨兵集羣須要解決
          • 故障發現、和master決策的協商機制問題
  • sentinel之間的相互感知
    • sentinel節點之間會由於共同監視同一個master從而產生了關聯,
      • 一個新加入的sentinel節點須要和其餘監視相同master節點的sentinel相互感知
        • 須要相互感知的sentinel都向他們共同監視的master節點訂閱
          • channel:sentinel:hello
        • 新加入的sentinel節點向這個channel發佈一條消息,
          • 包含本身自己的信息,
          • 這樣訂閱了這個channel的sentinel就能夠發現這個新的sentinel
        • 新加入的sentinel和其餘sentinel節點創建長鏈接

master的故障發現數據庫

  • sentinel節點會按期向master節點發送心跳包來判斷存活狀態,
    • 一旦master節點沒有正確響應,
    • sentinel會把master設置爲「主觀不可用狀態」,
    • 而後它會把「主觀不可用」發送給其餘全部的sentinel節點去確認,
    • 當確認的sentinel節點數大於>quorum時,
    • 則會認爲master是「客觀不可用」,
    • 接着就開始進入選舉新的master流程
      • 那誰來決策選擇哪一個節點做爲maste呢?
        • 這裏用到了一致性算法Raft算法(該算法用於哨兵的Master選舉)、它和Paxos算法相似,都是分佈式一致性算法。
          • redis的master選舉的時候會考慮slave的一些信息: 
            • 跟master斷開鏈接的時長 
            • slave優先級 
            • 複製offset 
            • run id 
        • 可是它比Paxos算法要更容易理解;
        • Raft和Paxos算法同樣,也是基於投票算法,
          • 只要保證過半數節點經過提議便可;

配置實現服務器

  • 在其中任意一臺服務器上建立一個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
  • 兩種方式啓動哨兵
    • 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角色加入到整個集羣中
相關文章
相關標籤/搜索