如果我們不用哨兵，如何實現主從故障的轉移呢？這事兒得手動來實現：
1、在從節點slave-1執行 slaveof no one ，將從節點變為主節點；
2、其它的節點，執行 slaveof slave-1的ip port，變為slave-1的從節點，並從新節點復制數據；
當然，有了哨兵機制我們就不用這么費事兒了，它的原理就是用raft算法實現選舉機制，選出一個哨兵節點(哨兵也有主節點)來完成轉移和通知；
哨兵有三個定時監控任務完成對各節點的發現和監控：
任務1，每個哨兵節點每10秒會向主節點和從節點發送info命令獲取最新拓撲結構圖，哨兵配置時只要配置對主節點的監控即可(sentinel monitor mymaster 192.168.1.3 26379 2)，通過向主節點發送info，獲取從節點的信息，並當有新的從節點加入時可以馬上感知到；
任務2，每個哨兵節點每隔2秒會向redis數據節點的指定頻道上發送該哨兵節點對於主節點的判斷以及當前哨兵節點的信息，同時每個哨兵節點也會訂閱該頻道，來了解其它哨兵節點的信息及對主節點的判斷，其實就是通過消息publish和subscribe來完成的；
任務3，每隔1秒每個哨兵會向主節點、從節點及其余哨兵節點發送一次ping命令做一次心跳檢測，這個也是哨兵用來判斷節點是否正常的重要依據；
任務1 任務2 任務3
主觀下線和客觀下線：
主觀下線：剛我知道知道哨兵節點每隔1秒對主節點和從節點、其它哨兵節點發送ping做心跳檢測，當這些心跳檢測時間超過down-after-milliseconds時，哨兵節點則認為該節點錯誤或下線，這叫主觀下線；這可能會存在錯誤的判斷。
客觀下線：當主觀下線的節點是主節點時，此時該哨兵3節點會通過指令sentinel is-masterdown-by-addr尋求其它哨兵節點對主節點的判斷，當超過quorum（法定人數）個數，此時哨兵節點則認為該主節點確實有問題，這樣就客觀下線了，大部分哨兵節點都同意下線操作，也就說是客觀下線
領導者哨兵選舉流程：
a、每個在線的哨兵節點都可以成為領導者，當它確認（比如哨兵3）主節點下線時，會向其它哨兵發is-master-down-by-addr命令，征求判斷並要求將自己設置為領導者，由領導者處理故障轉移；
b、當其它哨兵收到此命令時，可以同意或者拒絕它成為領導者；
c、如果哨兵3發現自己在選舉的票數大於等於num(sentinels)/2+1時，將成為領導者，如果沒有超過，繼續選舉…………
故障轉移機制
A，由Sentinel節點定期監控發現主節點是否出現了故障，sentinel會向master發送心跳PING來確認master是否存活，如果master在“一定時間范圍”內不回應PONG 或者是回復了一個錯誤消息，那么這個sentinel會主觀地(單方面地)認為這個master已經不可用了，會要求其他sentinel確認該節點是否丟失，如果確認，則認為是客觀下線，的確不可用了，開始進行故障轉移；
B，當主節點出現故障，此時3個Sentinel節點共同選舉了Sentinel3節點為領導，負載處理主節點的故障轉移,
C，由Sentinel3領導者節點執行故障轉移，過程和主從復制一樣，但是自動執行
流程： 1，將slave-1脫離原從節點，升級主節點，
2，將從節點slave-2指向新的主節點
3，通知客戶端主節點已更換
4，將原主節點（oldMaster）變成從節點，指向新的主節點
D，故障轉移后的redis sentinel的拓撲結構圖
哨兵機制－故障轉移詳細流程
A，過濾掉不健康的（下線或斷線），沒有回復過哨兵ping響應的從節點
B，選擇salve-priority從節點優先級最高（redis.conf）
C，選擇復制偏移量最大，指復制最完整的從節點
哨兵部分，over