一.出現的背景：
redis 主從復制模式下一旦主節點由于故障不能提供服務，需要人工將從節點晉升為主節點，同時還要通知應用方更新主節點地址，對于很多應用這種場景的這種故障處理方式是非常浪費人力的。為了提供Redis主從的高可用性，Redis從2.8版本開始提供Redis Sential（哨兵）架構來解決問題。
二.架構圖：
三.Redis Sentinel的高可用方案主要介紹：
由上圖可以看到Redis Sentinel是一個分布式架構，包含若干個Sentinel節點和Redis數據節點，每個Sentinel節點會對數據節點和其余Sentinel節點進行監控，當它發現節點不可達時，會對節點做下線標識，如果被標識的是主節點，它還會和其他Sentinel節點進行“協商”，當大多數Sentinel節點都認為主節點不可達時他們會選舉出一個Sentinel節點來完成自動故障轉移的工作，選舉出新的主節點，將老的主節點降級為從節點，同時會將這個變化實時通知給Redis應用方。
四.基本實現原理：
1.執行三個定時任務用于獲取及同步各端(主節點、從節點、Sentinel節點)信息：
A.每隔10秒獲得主從節點信息；（通過info命令）
B.每隔2秒同步主節點及當前sentinel節點信息； （通過redis的訂閱功能）
C.每隔1秒各個Sentinel節點實現同其他端之間的心跳檢測；（通過ping命令）
2.下線有問題的節點:
主觀下線：每個Sentinel節點會每隔1秒對主從節點及其他Sentinel節點發送ping命令做心跳檢測，當這些節點超過down-after-milliseconds沒有進行有效回復時Sentinel節點會對該節點做失敗判定，這個行為即主觀下線。（該主觀下線的判定是當前一個Sentinel的判定所以也存在誤判的可能，比如剛好那時的網絡問題）
客觀下線：當Sentinel接待主觀下線的是主節點時，該Sentinel會通過sentinel is-master-down-by-addr命令其他Sentinel節點詢問對主節點的判斷，當超過quorum（判定主節點最終不可達所需的票數）個數時，Sentinel節點會認為該主節點確實有問題，這時Sentinel節點會做出客觀下線的決定。
3.領導者Sentinel節點選舉(Raft算法)用于去做故障轉移的leader（即選誰去領導這次故障轉移，現實中一般是誰先發現了這個故障誰就成為leader的可能性最大，而且這個選舉的過程很快）。
該選舉過程主要包含：
(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),那么它將成為領導者。（現實中一旦一個Sentinel節點獲得了max(quorum，num(sentinels)/2+1) 的票數，其他Sentinel節點再去確認已經沒有意義因為每個Sentinel節點只有一票）
(4)如果此過程沒有選舉出領導者，則將進入下一次類似這樣的選舉。
4.故障轉移：
(1).Sentine領導者節點從從節點列表中選出一個節點作為新的主節點，選擇過程如下圖：
(2).Sentinel領導者節點會對第一步選出來的從節點執行slaveof no one命令讓其成為主節點。
(3).Sentinel領導者節點會向剩余的從節點發送命令，并讓他們成為新主節點的從節點。
(4)Sentinel節點集合將原來的主節點更新為從節點，并保持對其關注，當其回復后命令它去復制新的主節點數據。
