Redis的高可用(原理篇)
3個定時監控任務
1. 每隔10s，每個Sentinel節點會向主節點和從節點發送info命令獲取最新的拓撲結構。
$ redis-cli -p 6481 -a abcdefg monitor | egrep '127.0.0.1:51934.*INFO'
1532419769.058192 [0 127.0.0.1:51934] "INFO"
1532419779.081816 [0 127.0.0.1:51934] "INFO"
1532419789.089331 [0 127.0.0.1:51934] "INFO"
1532419799.118555 [0 127.0.0.1:51934] "INFO"
$ netstat -atunlp | grep 51934
tcp 0 0 127.0.0.1:51934 127.0.0.1:6481 ESTABLISHED 23418/redis-sentine
tcp 0 0 127.0.0.1:6481 127.0.0.1:51934 ESTABLISHED 24055/redis-server
2. 每隔2s，每個Sentinel節點會向Redis數據節點的__sentinel__:hello頻道發送該Sentinel節點對於主節點的判斷以及當前Sentinel節點的信息。另外每個Sentinel節點會訂閱一組事件頻道(如+sdown頻道，發布主觀下線的消息)，共享Sentinel節點間的事件。
$ redis-cli -p 6481 -a abcdefg monitor | egrep '127.0.0.1:51934.*PUBLISH'
1532420062.524075 [0 127.0.0.1:51934] "PUBLISH" "__sentinel__:hello" "127.0.0.1,26481,2e1df3bfaad006ad90295492eef2bc9b923abbf1,4,sfmaster,127.0.0.1,6481,4"
1532420064.531796 [0 127.0.0.1:51934] "PUBLISH" "__sentinel__:hello" "127.0.0.1,26481,2e1df3bfaad006ad90295492eef2bc9b923abbf1,4,sfmaster,127.0.0.1,6481,4"
1532420066.617168 [0 127.0.0.1:51934] "PUBLISH" "__sentinel__:hello" "127.0.0.1,26481,2e1df3bfaad006ad90295492eef2bc9b923abbf1,4,sfmaster,127.0.0.1,6481,4"
1532420068.667024 [0 127.0.0.1:51934] "PUBLISH" "__sentinel__:hello" "127.0.0.1,26481,2e1df3bfaad006ad90295492eef2bc9b923abbf1,4,sfmaster,127.0.0.1,6481,4"
$ redis-cli -p 26479 -a abcdefg subscribe +sdown
...
1) "message"
2) "+sdown"
3) "master sfmaster 127.0.0.1 6480"
$ redis-cli -p 26480 -a abcdefg subscribe +odown
...
1) "message"
2) "+odown"
3) "master sfmaster 127.0.0.1 6480 #quorum 2/2"
3. 每隔1s，每個Sentinel節點會向主節點，從節點，其余Sentinel節點發送一條ping命令做心跳檢測，確認這些節點是否可達。
$ redis-cli -p 6481 -a abcdefg monitor | egrep '127.0.0.1:39042.*PING'
1532421426.017054 [0 127.0.0.1:39042] "PING"
1532421427.034552 [0 127.0.0.1:39042] "PING"
1532421428.049429 [0 127.0.0.1:39042] "PING"
1532421429.079257 [0 127.0.0.1:39042] "PING"
主觀下線和客觀下線
1. 主觀下線
每個Sentinel節點間隔1s對主節點，從節點，其它Sentinel節點發送ping命令做心跳檢測，當這些節點超過down-after-milliseconds沒進行有效回復時，Sentinel節點就會對該節點做不可達判定，該行為叫主觀下線。
2. 客觀下線
當Sentinel主觀下線的節點是主節點時，該Sentinel節點會通過sentinel is-master-down-by-addr命令，向其它Sentinel節點詢問對主節點的判斷，當超過<quorum>個Sentinel節點認為主節點有問題時，該Sentinel節點會做客觀下線決定。
從主觀下線到客觀下線的過程，Redis沒有使用什麽一致性算法，僅依據gossip協議在有效時間範圍內收到其它Sentinel節點的確認即可。
領導者Sentinel節點選舉
某Sentinel節點對主節點做客觀下線後，需要選舉出領導者進行故障轉移工作，Redis使用了Raft算法實現領導者選舉，大致思路如下。
1. 每個Sentinel節點都有資格成為領導者，當它對主節點做客觀下線後，會向其它Sentinel節點發送sentinel is-master-down-by-addr，要求把自己選舉為領導者。
2. 收到命令的Sentinel節點，如果沒有同意過其它Sentinel節點的sentinel is-master-down-by-addr命令，將同意該請求，否則拒絕。
3. 如果該Sentinel節點發現自己的票數大於等於max(quorum,num(sentinels/2)+1)了，那麽它將成為領導者。
4. 若此過程沒有選舉出領導者，將進入下一輪選舉。
故障轉移
選舉出的領導者Sentinel節點負責故障轉移，具體步驟如下。
1. 在從節點中找出一個合適節點作為新的主節點。
2. 領導者Sentinel節點會對選出來的從節點執行slaveof no one命令，讓其成為主節點。
3. 領導者Sentinel節點會向剩余的從節點發送命令，讓它們成為新主節點的從節點，復制規則和參數parallel-syncs有關。
4. Sentinel節點集合會將原來的主節點在配置文件中更新為從節點，當其恢復後命令它去復制新的主節點。
若感興趣可關註訂閱號”數據庫最佳實踐”(DBBestPractice).
Redis的高可用(原理篇)