前言：
緊接上篇主從模式，爲了解決主從的主節點故障時，不能切換的問題，引入了哨兵(sentinel)模式。
一.介紹
根據官網https://redis.io/topics/sentinel的介紹，哨兵模式是redis提供的一套高可用的解決方案，用來面對redis失敗的時，不需要人爲去幹涉。
Sentinel的當前版本稱爲Sentinel 2。它使用更強大且更易於預測的算法（在本文檔中進行了說明）重寫了Sentinel的初始實現。
自Redis 2.8起已發佈穩定版本的Redis Sentinel。
在不穩定分支中進行了新的開發，並且有時新功能一旦被認爲是穩定的，便會立即移植回最新的穩定分支。
Redis 2.6附帶的Redis Sentinel版本1已被棄用，不應使用。
根據官方文檔介紹，哨兵(sentinel)模式在宏觀層面有以下的作用。
- Monitoring. Sentinel constantly checks if your master and replica instances are working as expected.
- Notification. Sentinel can notify the system administrator, or other computer programs, via an API, that something is wrong with one of the monitored Redis instances.
- Automatic failover. If a master is not working as expected, Sentinel can start a failover process where a replica is promoted to master, the other additional replicas are reconfigured to use the new master, and the applications using the Redis server are informed about the new address to use when connecting.
- Configuration provider. Sentinel acts as a source of authority for clients service discovery: clients connect to Sentinels in order to ask for the address of the current Redis master responsible for a given service. If a failover occurs, Sentinels will report the new address.
1.監控(Monitoring) :哨兵(sentinel)會不斷檢查你的主節點(master)和從節點(slave)是否正常的運行
2.通知(Notification):當檢查到某個redis實例出錯時,哨兵(sentinel)可以通過API告知其他程序
3.自動故障遷移(Automatic failover):如果一個主節點(master)不能正常工作的時候，:哨兵(sentinel)可以開啓 故障切換進程，裏面的一個從節點(replica)會被提升做主節點(master)，然後其他的從節點會被使用這個新的主節點(master)重新配置，當其他使用這個redis服務的程序連接redis服務時也會被告知這個新的地址
4.環境配置提供者(Configuration provider):哨兵作爲客戶端服務發現的授權源：客戶端連接哨兵時詢問當前redis主節點的地址，當發生故障遷移時，哨兵會報告新地址。
哨兵(sentinel)模式的工作原理
Redis Sentinel具有兩個不同關閉概念，一個稱爲主觀關閉狀態（SDOWN），它是給定Sentinel實例本地的關閉狀態。另一個稱爲客觀停機 狀態（ODOWN），當足夠多的Sentinels（至少是配置爲quorum受監視主服務器的參數的數量）達到SDOWN條件並使用該SENTINEL is-master-down-by-addr命令從其他Sentinels獲得反饋時，就會達到該狀態。
從Sentinel的角度來看，如果在配置中指定的秒數內未收到對PING請求的有效回覆，則達到SDOWN條件is-master-down-after-milliseconds 。
可接受的對PING的答覆是以下一種：
- PING回覆了+ PONG。
- PING答覆-LOADING error。
- PING答覆-MASTERDOWN error。
任何其他答覆（或根本沒有答覆）均被視爲無效。但是請注意，在INFO輸出中將自己作爲副本發佈的邏輯主節點(master)被視爲已關閉。
一個如果一個節點在起設置的間隔時間範圍內沒有接受到有效的答覆，則認爲該節點SDOWN。如果一個節點在29s接收到有效的回覆則認爲該節點在工作（其間隔時間爲30000ms即30s）
但是SDOWN是不足以出發故障遷移的，要觸發此狀態，需要達到ODOWN狀態。
判定一個節點是否是ODOWN很簡單，只需要有足夠多的sentinel認爲該節點在給點時間範圍內沒有工作，則認爲該節點ODOWN。同時也需要注意到ODOWN狀態只適用於master。
二.配置
根據官網以下是最小配置
# mymaster是給master自己取名字 監控本機的ip,端口爲6379，2爲仲裁係數(quorum)，當有兩個以上sentinel認爲該master不工作時，開啓故障遷移
sentinel monitor mymaster 127.0.0.1 6379 2
#down-after-milliseconds是指在指定時間內沒有範圍ping的結果或者帶ping的錯誤信息的所設置的毫秒數(判斷爲主觀下線SDOWN)
sentinel down-after-milliseconds mymaster 60000
#指過一段時間後，再對該節點進行故障遷移
sentinel failover-timeout mymaster 180000
#指定了在執行故障轉移時， 最多可以有多少個從服務器同時對新的主服務器進行同步， 這個數字越小， 完成故障轉移所需的時間就越長，但越大就意味着越多的從服務器因爲複製而不可用。可以通過將這個值設爲 1 來保證每次只有一個從服務器處於不能處理命令請求的狀態。
sentinel parallel-syncs mymaster 1
我本地的配置
#當前Sentinel服務運行的端口
protected-mode no
bind 127.0.0.1
port 10001
sentinel monitor mymaster 127.0.0.1 6379 1
sentinel down-after-milliseconds mymaster 3000
sentinel failover-timeout mymaster 10000
# 設置哨兵sentinel 連接主從的密碼 注意必須爲主從設置一樣的驗證密碼，沒有的話不用設置
sentinel auth-pass mymaster 123456
需要注意一下，redis推薦最少三臺的sentinel來保證其健壯性。
觸發failover的條件有二：
1.認爲master爲ODOWN>=上面的仲裁係數（quorum）
2.大多數的sentinel之間能夠通信。當只有兩臺sentinel的時候，大多數爲2；3臺sentinel的時候，大多數爲2,5臺sentinel的時候大多數爲3.
三.配置實戰
3.1.在redis文件下新建sentinel.conf文件
#當前Sentinel服務運行的端口
protected-mode no
bind 127.0.0.1
port 10001
sentinel monitor mymaster 127.0.0.1 6379 1
sentinel down-after-milliseconds mymaster 3000
sentinel failover-timeout mymaster 10000
# 設置哨兵sentinel 連接主從的密碼 注意必須爲主從設置一樣的驗證密碼，沒有的話不用設置
sentinel auth-pass mymaster 123456
因爲我是在同一臺電腦下啓動，不同的sentinel用不同的port。（s1->10001,s2->10002,s3->10003）
3.2.先啓動redis的master和slave（windows下可參考我上邊文章，linux的自己查一下）。
3.3在redis目錄下cmd進入，執行redis-server.exe sentinel.conf --sentinel命令
這樣我們就在本機啓動兩個redis,三個sentinel了
3.4關閉redis 的master
通過vote，redis主節點從6380轉到6379
