redis主機默認是10s發送一次心跳給從節點。
從節點默認1s去發送心跳給主節點。
1、原理
當主節點出現故障時，由Redis Sentinel自動完成故障發現和轉移，并通知應用方，實現高可用性。
從節點的主要兩個作用：
- 主節點的數據備份。
- 實現讀寫分離
2、部署架構
為了防止哨兵宕機，因此哨兵也是需要多臺部署，不少于3臺.
哨兵本身也是一臺redis節點，只是充當監控的角色，不參與業務操作，不存儲數據
3、哨兵實現原理
按照上圖的部署架構，哨兵依賴于3個定時任務去實現監控和故障轉移。
定時任務作用一
1.sentinel節點向主從節點發送一次info命令.就可以得到主從的拓撲結構。
//例如有新的從節點加入，執行slaveof命令后，哨兵會再下一次info命令后感知到新的拓撲結構。
2.同理，主機或者某一個從節點宕機，那么哨兵再次執行info命令的時候，會感知到新的哨兵結構，做出對應的操作.
定時任務作用二
每隔2s的一次publish/subscribe
1. 哨兵1,2，3會向redis中的數據節點發送發布訂閱命令。
2. 目的是為了感知新加入的哨兵節點，以及在哨兵之間交互主節點的狀態。
定時任務作用三
每隔1s發送一次ping
1.例如，哨兵3每隔1s向哨兵1,2，主節點，從節點發送一次ping心跳。
//首先是判斷各個節點是否存活
由此可以看出，哨兵還是挺忙的，忙著故障的恢復和轉移
哨兵與主從的通訊
4、主管下載，客觀下線，領導者選舉
達到客觀下線的條件后，開啟領導者哨兵選舉
誰先發現下線，誰就是哨兵的領導者
5、故障轉移
1. 哨兵從從節點列表中，選擇一臺從節點。
2. 過濾掉不監控的從節點，一般是5s內沒有回復pong的。
3. 如果兩個從節點都是健康的，則選擇那個優先級高的。優先級是可以配置的
4. 如果以上不滿足，則選擇復制最完整的節點來充當主節點。
5. 如果還不滿足，則選擇runid最小的節點。runid最小表示是最早啟動的節點。
哨兵完成主從切換后，對于Java客戶端來說，是無感知的，客戶端如何操作呢？不可能去修改配置文件的。
通過JedisSentinelPool實現在客戶端的主從切換
)
