Redis Sentinel

Redis Sentinel

架構

redis sentinel故障轉移的步驟

1. 多個sentinel發現卻確認master有問題
2. 選舉出一個sentinel做爲領導
3. 選出一個slave做爲master
4. 通知其他的slave成爲新的master的slave
5. 通知客戶端主從變化
6. 等待老的master復活成爲新的master的slave

redis sentinel的安裝和配置

在這此前提是你如今當前的集羣已經實現了redis的主從複製，要不沒法實現如下的功能，若是尚未配置的能夠找找我以前寫的文章

redis sentinel的配置

mymaster是我所監控的主節點的名字

port ${port}
daemonize yes
dir "XXX"#工做的目錄
logfile "${port}.log"#由於有多個sentinel因此習慣性用端口來命令，容易區分日誌
sentinel monitor mymaster 127.0.0.1 7000 2#表示有2臺sentinel認爲這個主節點有問題了，就會開始對它進行下限
sentinel down-after-milliseconds mymaster 30000#sentinel用於檢測主節點是否還能連通，能夠想象就是ping了以後30000毫秒不通就認爲是斷開
sentinel parallel-syncs mymaster 1#當主節點發生變化的時候，其他的從節點是如何複製主節點的數據，1是一個個來複制，0是同時進行復制，一個個來會減小主庫的壓力
sentinel failover-timeout mymaster 1800000#故障轉移的時間

在咱們的redis（我使用的是redis-4）中會已經有sentinel的模版，能夠在經過這個模版進行一些修改配置

cat sentinel.conf |grep -v '#'|grep -v '^$'#能夠去除空格和註釋,這樣便於修改

修改完成以後能夠啓動

./redis-sentinel ../config/redis-sentinel-26382.cnf（配置文件目錄）#和啓動redis-server是同樣的

啓動完以後，由於sentinel是特殊的redis，能夠經過正常的方式啓動，例如

redis-cli -p 26382

以後在執行info命令能夠看出，sentinel已經知道這個集羣的架構，有多少個從庫

這是咱們回過頭去看，會發現配置已經發生了變化

而後咱們能夠按照本身的需求配置多個sentinel，並啓動

在我配置的過程當中，由於我是在一臺服務器上進行，因此只是端口的差別，這樣咱們能夠用一些命令去偷懶，哈哈

sed 's/26382/26384/g' redis-sentinel-26382.cnf > redis-sentinel-26384.cnf #這樣就能夠把redis-sentinel-26382.cnf的26382所有改成26384

具體的命令詳情，本身去查詢如下哈，由於不是我學習的重點，因此就沒寫了

我本身在測試的時候，我是啓動了三個sentinel，把他們都配置完成並啓動以後，執行info命令會發現

他們也互相得感知到了，檢測到了當前集羣有3個sentinel在管理中

三個定時任務

是爲了讓每一個sentinel和redis節點保持鏈接，出現問題後能夠準確地快速切換

1.每10秒每一個sentinel對master和slave執行info

• 發現slave節點
• 確認主從關係

2.每2秒每一個sentinel經過master節點的channel交換信息（pub/sub，即發佈訂閱）

• 經過master的內部頻道（_sentinel_:hello）進行交互
• 交互對節點的「見解」和自身的信息
• 當有新的sentinel節點加入進來也會自動地加入該頻道和其餘的sentinel節點進行通訊

3.每1秒每一個sentinel對其餘的sentinel和redis執行ping

• 故障檢查
• 心跳檢測，失敗斷定依據

主觀下線和客觀下線

當監控正在master的sentinel發現master出現問題了，就採起下線操做。
面前咱們有提到兩個配置

sentinel monitor mymaster 127.0.0.1 7000 2(quorum)
sentinel down-after-milliseconds mymaster 30000

主觀下線：是單個sentinel節點對redis節點失敗的「偏見」
客觀下線：全部的sentinel節點對redis節點失敗「達成共識」（quorum,能夠自行根據須要配置）

如何認爲master失敗呢？
sentinel節點ping超過了第二條配置中設置的時間以後沒有迴應就認爲是失敗

當一個sentinel發現了問題，就會向其餘的sentinel節點內部會發送sentinel is_master_down_by_addr去「諮詢」其餘sentinel的意見

領導者選舉

在集羣中，雖然有多個sentinel進行監控，可是隻有一個sentinel節點完成故障轉移

1. 當一個節點發現問題以後會向其餘的sentinel節點發送sentinel is_master_down_by_addr「諮詢」其餘sentinel的意見，同時也「發表」了要求將它設置爲領導者
2. 收到命令的sentinel節點若是沒有贊成經過其餘的sentinel節點發送的命令，那麼將贊成該請求，不然拒絕
3. 若是該sentinel節點發現本身的票數已經超過sentinel集合半數且超過（quorum），那麼它將成爲領導者
4. 若是此過程有多個sentinel節點成爲了領導者，那麼將等待一段時間從新進行選舉

故障轉移（sentinel 領導者節點完成）

1. 從slave節點中選出一個「合適的」節點做爲新的master節點
2. 對上面的slave節點執行slave no one命令讓其成爲master節點
3. 向剩餘的slave節點發送命令，讓他們成爲新的master節點的slave節點，複製的規則和parallvel_syncs參數有關;sentinel parallel-syncs mymaster 1#當主節點發生變化的時候，其他的從節點是如何複製主節點的數據，1是一個個來複制，0是同時進行復制，一個個來會減小主庫的壓力`
4. 將更新對原來的master節點配置爲slave，並保持對其的「關注」，當其恢復後命令它去複製新的master節點

如何選舉「合適的」slave節點

1. 選擇slave_priority(slave節點的優先級)最高的slave節點，若是存在即返回，不存在則繼續
2. 選擇複製偏移量最大的slave節點（複製得最完整），若是存在即返回，不存在則繼續
3. 選擇runid最小的slave節點