Redis哨兵模式（sentinel）集群環境（主從複製、讀寫分離、主從切換）虛擬機下載

Redis的集群方案大致有三種：1）redis cluster集群方案；2）master/slave主從方案；3）哨兵模式來進行主從替換以及故障恢復。

一、sentinel哨兵模式介紹
Sentinel(哨兵)是用於監控redis集群中Master狀態的工具，是Redis 的高可用性解決方案，sentinel哨兵模式已經被集成在redis2.4之後的版本中。sentinel是redis高可用的解決方案，sentinel系統可以監視一個或者多個redis master服務，以及這些master服務的所有從服務；當某個master服務下線時，自動將該master下的某個從服務升級為master服務替代已下線的master服務繼續處理請求。

Redis-Sentinel是Redis官方推薦的高可用性(HA)解決方案，當用Redis做Master-slave的高可用方案時，假如master宕機了，Redis本身(包括它的很多客戶端)都沒有實現自動進行主備切換，而Redis-sentinel本身也是一個獨立運行的進程，它能監控多個master-slave集群，發現master宕機後能進行自動切換。Sentinel由一個或多個Sentinel 實例 組成的Sentinel 系統可以監視任意多個主服務器，以及這些主服務器屬下的所有從服務器，並在被監視的主服務器進入下線狀態時，自動將下線主服務器屬下的某個從服務器升級為新的主服務器。

例如下圖所示：

在Server1 掉線後：

升級Server2 為新的主服務器：

Sentinel版本
Sentinel當前最新的穩定版本稱為Sentinel 2(與之前的Sentinel 1區分開來）。隨着redis2.8的安裝包一起發行。安裝完Redis2.8後，可以在redis2.8/src/裏面找到Redis-sentinel的啟動程序。
強烈建議：如果你使用的是redis2.6(sentinel版本為sentinel 1)，你最好應該使用redis2.8版本的sentinel 2，因為sentinel 1有很多的Bug，已經被官方棄用，所以強烈建議使用redis2.8以及sentinel 2。

Sentinel狀態持久化
snetinel的狀態會被持久化地寫入sentinel的配置文件中。每次當收到一個新的配置時，或者新創建一個配置時，配置會被持久化到硬盤中，並帶上配置的版本戳。這意味着，可以安全的停止和重啟sentinel進程。

Sentinel作用： 
1）Master狀態檢測
2）如果Master異常，則會進行Master-Slave切換，將其中一個Slave作為Master，將之前的Master作為Slave。
3）Master-Slave切換後，master_redis.conf、slave_redis.conf和sentinel.conf的內容都會發生改變，即master_redis.conf中會多一行slaveof的配置，sentinel.conf的監控目標會隨之調換。

Sentinel工作方式（每個Sentinel實例都執行的定時任務）
1）每個Sentinel以每秒鐘一次的頻率向它所知的Master，Slave以及其他 Sentinel 實例發送一個PING命令。
2）如果一個實例（instance）距離最後一次有效回復PING命令的時間超過 own-after-milliseconds 選項所指定的值，則這個實例會被Sentinel標記為主觀下線。
3）如果一個Master被標記為主觀下線，則正在監視這個Master的所有 Sentinel 要以每秒一次的頻率確認Master的確進入了主觀下線狀態。
4）當有足夠數量的Sentinel（大於等於配置文件指定的值）在指定的時間範圍內確認Master的確進入了主觀下線狀態，則Master會被標記為客觀下線。
5）在一般情況下，每個Sentinel 會以每10秒一次的頻率向它已知的所有Master，Slave發送 INFO 命令。
6）當Master被Sentinel標記為客觀下線時，Sentinel 向下線的 Master 的所有Slave發送 INFO命令的頻率會從10秒一次改為每秒一次。
7）若沒有足夠數量的Sentinel同意Master已經下線，Master的客觀下線狀態就會被移除。 若 Master重新向Sentinel 的PING命令返回有效回復，Master的主觀下線狀態就會被移除。

三個定時任務
sentinel在內部有3個定時任務
1）每10秒每個sentinel會對master和slave執行info命令，這個任務達到兩個目的：
a）發現slave節點
b）確認主從關係
2）每2秒每個sentinel通過master節點的channel交換信息（pub/sub）。master節點上有一個發佈訂閱的頻道(__sentinel__:hello)。sentinel節點通過__sentinel__:hello頻道進行信息交換(對節點的”看法”和自身的信息)，達成共識。
3）每1秒每個sentinel對其他sentinel和redis節點執行ping操作（相互監控），這個其實是一個心跳檢測，是失敗判定的依據。

本博主配置好基於sentinel模式的Redis集群環境（主從複製、讀寫分離、主從切換）虛擬機下載，鏈接：https://pan.baidu.com/s/1t1DzlhiBFzlDqJkmzNj83Q
提取碼：y26r 下載後，用Vmware Workstation打開就可以使用

主觀下線
所謂主觀下線（Subjectively Down， 簡稱 SDOWN）指的是單個Sentinel實例對服務器做出的下線判斷，即單個sentinel認為某個服務下線（有可能是接收不到訂閱，之間的網絡不通等等原因）。
主觀下線就是說如果服務器在down-after-milliseconds給定的毫秒數之內， 沒有返回 Sentinel 發送的 PING 命令的回復， 或者返回一個錯誤， 那麼 Sentinel 將這個服務器標記為主觀下線（SDOWN ）。
sentinel會以每秒一次的頻率向所有與其建立了命令連接的實例（master，從服務，其他sentinel）發ping命令，通過判斷ping回復是有效回復，還是無效回復來判斷實例時候在線（對該sentinel來說是「主觀在線」）。
sentinel配置文件中的down-after-milliseconds設置了判斷主觀下線的時間長度，如果實例在down-after-milliseconds毫秒內，返回的都是無效回復，那麼sentinel回認為該實例已（主觀）下線，修改其flags狀態為SRI_S_DOWN。如果多個sentinel監視一個服務，有可能存在多個sentinel的down-after-milliseconds配置不同，這個在實際生產中要注意。

客觀下線
客觀下線（Objectively Down， 簡稱 ODOWN）指的是多個 Sentinel 實例在對同一個服務器做出 SDOWN 判斷， 並且通過 SENTINEL is-master-down-by-addr 命令互相交流之後， 得出的服務器下線判斷，然後開啟failover。
客觀下線就是說只有在足夠數量的 Sentinel 都將一個服務器標記為主觀下線之後， 服務器才會被標記為客觀下線（ODOWN）。
只有當master被認定為客觀下線時，才會發生故障遷移。
當sentinel監視的某個服務主觀下線後，sentinel會詢問其它監視該服務的sentinel，看它們是否也認為該服務主觀下線，接收到足夠數量（這個值可以配置）的sentinel判斷為主觀下線，既任務該服務客觀下線，並對其做故障轉移操作。
sentinel通過發送 SENTINEL is-master-down-by-addr ip port current_epoch runid，（ip：主觀下線的服務id，port：主觀下線的服務端口，current_epoch：sentinel的紀元，runid：*表示檢測服務下線狀態，如果是sentinel 運行id，表示用來選舉領頭sentinel）來詢問其它sentinel是否同意服務下線。
一個sentinel接收另一個sentinel發來的is-master-down-by-addr後，提取參數，根據ip和端口，檢測該服務時候在該sentinel主觀下線，並且回復is-master-down-by-addr，回復包含三個參數：down_state（1表示已下線，0表示未下線），leader_runid（領頭sentinal id），leader_epoch（領頭sentinel紀元）。
sentinel接收到回復後，根據配置設置的下線最小數量，達到這個值，既認為該服務客觀下線。
客觀下線條件只適用於主服務器： 對於任何其他類型的 Redis 實例， Sentinel 在將它們判斷為下線前不需要進行協商， 所以從服務器或者其他 Sentinel 永遠不會達到客觀下線條件。只要一個 Sentinel 發現某個主服務器進入了客觀下線狀態， 這個 Sentinel 就可能會被其他 Sentinel 推選出， 並對失效的主服務器執行自動故障遷移操作。

在redis-sentinel的conf文件里有這麼兩個配置：
1）sentinel monitor <masterName> <ip> <port> <quorum>

四個參數含義：
masterName這個是對某個master+slave組合的一個區分標識（一套sentinel是可以監聽多套master+slave這樣的組合的）。
ip 和 port 就是master節點的 ip 和 端口號。
quorum這個參數是進行客觀下線的一個依據，意思是至少有 quorum 個sentinel主觀的認為這個master有故障，才會對這個master進行下線以及故障轉移。因為有的時候，某個sentinel節點可能因為自身網絡原因，導致無法連接master，而此時master並沒有出現故障，所以這就需要多個sentinel都一致認為該master有問題，才可以進行下一步操作，這就保證了公平性和高可用。

2）sentinel down-after-milliseconds <masterName> <timeout>
這個配置其實就是進行主觀下線的一個依據，masterName這個參數不用說了，timeout是一個毫秒值，表示：如果這台sentinel超過timeout這個時間都無法連通master包括slave（slave不需要客觀下線，因為不需要故障轉移）的話，就會主觀認為該master已經下線（實際下線需要客觀下線的判斷通過才會下線）

那麼，多個sentinel之間是如何達到共識的呢？
這就是依賴於前面說的第二個定時任務，某個sentinel先將master節點進行一個主觀下線，然後會將這個判定通過sentinel is-master-down-by-addr這個命令問對應的節點是否也同樣認為該addr的master節點要做客觀下線。最後當達成這一共識的sentinel個數達到前面說的quorum設置的這個值時，就會對該master節點下線進行故障轉移。quorum的值一般設置為sentinel個數的二分之一加1，例如3個sentinel就設置2。本博主配置好基於sentinel模式的Redis集群環境（主從複製、讀寫分離、主從切換）虛擬機下載，鏈接：https://pan.baidu.com/s/1t1DzlhiBFzlDqJkmzNj83Q
提取碼：y26r 下載後，用Vmware Workstation打開就可以使用

主觀下線（SDOWN）和客觀下線（ODOWN）的更多細節
sentinel對於不可用有兩種不同的看法，一個叫主觀不可用(SDOWN),另外一個叫客觀不可用(ODOWN)。SDOWN是sentinel自己主觀上檢測到的關於master的狀態，ODOWN需要一定數量的sentinel達成一致意見才能認為一個master客觀上已經宕掉，各個sentinel之間通過命令SENTINEL is_master_down_by_addr來獲得其它sentinel對master的檢測結果。
從sentinel的角度來看，如果發送了PING心跳後，在一定時間內沒有收到合法的回復，就達到了SDOWN的條件。這個時間在配置中通過is-master-down-after-milliseconds參數配置。
當sentinel發送PING後，以下回復之一都被認為是合法的：
PING replied with +PONG.
PING replied with -LOADING error.
PING replied with -MASTERDOWN error.
其它任何回復（或者根本沒有回復）都是不合法的。

從SDOWN切換到ODOWN不需要任何一致性算法，只需要一個gossip協議：如果一個sentinel收到了足夠多的sentinel發來消息告訴它某個master已經down掉了，SDOWN狀態就會變成ODOWN狀態。如果之後master可用了，這個狀態就會相應地被清理掉。
正如之前已經解釋過了，真正進行failover需要一個授權的過程，但是所有的failover都開始於一個ODOWN狀態。
ODOWN狀態只適用於master，對於不是master的redis節點sentinel之間不需要任何協商，slaves和sentinel不會有ODOWN狀態。

配置版本號
為什麼要先獲得大多數sentinel的認可時才能真正去執行failover呢？
當一個sentinel被授權後，它將會獲得宕掉的master的一份最新配置版本號，當failover執行結束以後，這個版本號將會被用於最新的配置。因為大多數sentinel都已經知道該版本號已經被要執行failover的sentinel拿走了，所以其他的sentinel都不能再去使用這個版本號。這意味着，每次failover都會附帶有一個獨一無二的版本號。我們將會看到這樣做的重要性。而且，sentinel集群都遵守一個規則：如果sentinel A推薦sentinel B去執行failover，B會等待一段時間後，自行再次去對同一個master執行failover，這個等待的時間是通過failover-timeout配置項去配置的。從這個規則可以看出，sentinel集群中的sentinel不會再同一時刻並發去failover同一個master，第一個進行failover的sentinel如果失敗了，另外一個將會在一定時間內進行重新進行failover，以此類推。
redis sentinel保證了活躍性：如果大多數sentinel能夠互相通信，最終將會有一個被授權去進行failover.
redis sentinel也保證了安全性：每個試圖去failover同一個master的sentinel都會得到一個獨一無二的版本號。

配置傳播
一旦一個sentinel成功地對一個master進行了failover，它將會把關於master的最新配置通過廣播形式通知其它sentinel，其它的sentinel則更新對應master的配置。
一個faiover要想被成功實行，sentinel必須能夠向選為master的slave發送SLAVEOF NO ONE命令，然後能夠通過INFO命令看到新master的配置信息。
當將一個slave選舉為master並發送SLAVEOF NO ONE後，即使其它的slave還沒針對新master重新配置自己，failover也被認為是成功了的，然後所有sentinels將會發佈新的配置信息。
新配在集群中相互傳播的方式，就是為什麼我們需要當一個sentinel進行failover時必須被授權一個版本號的原因。
每個sentinel使用##發佈/訂閱##的方式持續地傳播master的配置版本信息，配置傳播的##發佈/訂閱##管道是：__sentinel__:hello。
因為每一個配置都有一個版本號，所以以版本號最大的那個為標準。

舉個例子：
假設有一個名為mymaster的地址為192.168.10.202:6379。一開始，集群中所有的sentinel都知道這個地址，於是為mymaster的配置打上版本號1。一段時候後mymaster死了，有一個sentinel被授權用版本號2對其進行failover。如果failover成功了，假設地址改為了192.168.10.202:9000，此時配置的版本號為2，進行failover的sentinel會將新配置廣播給其他的sentinel，由於其他sentinel維護的版本號為1，發現新配置的版本號為2時，版本號變大了，說明配置更新了，於是就會採用最新的版本號為2的配置。
這意味着sentinel集群保證了第二種活躍性：一個能夠互相通信的sentinel集群最終會採用版本號最高且相同的配置。

sentinel的”仲裁會”
前面我們談到，當一個master被sentinel集群監控時，需要為它指定一個參數，這個參數指定了當需要判決master為不可用，並且進行failover時，所需要的sentinel數量，可以稱這個參數為票數

不過，當failover主備切換真正被觸發後，failover並不會馬上進行，還需要sentinel中的大多數sentinel授權後才可以進行failover。
當ODOWN時，failover被觸發。failover一旦被觸發，嘗試去進行failover的sentinel會去獲得「大多數」sentinel的授權（如果票數比大多數還要大的時候，則詢問更多的sentinel)
這個區別看起來很微妙，但是很容易理解和使用。例如，集群中有5個sentinel，票數被設置為2，當2個sentinel認為一個master已經不可用了以後，將會觸發failover，但是，進行failover的那個sentinel必須先獲得至少3個sentinel的授權才可以實行failover。
如果票數被設置為5，要達到ODOWN狀態，必須所有5個sentinel都主觀認為master為不可用，要進行failover，那麼得獲得所有5個sentinel的授權。

選舉領頭sentinel（即領導者選舉）
一個redis服務被判斷為客觀下線時，多個監視該服務的sentinel協商，選舉一個領頭sentinel，對該redis服務進行故障轉移操作。選舉領頭sentinel遵循以下規則：
1）所有的sentinel都有公平被選舉成領頭的資格。
2）所有的sentinel都有且只有一次將某個sentinel選舉成領頭的機會（在一輪選舉中），一旦選舉某個sentinel為領頭，不能更改。
3）sentinel設置領頭sentinel是先到先得，一旦當前sentinel設置了領頭sentinel，以後要求設置sentinel為領頭請求都會被拒絕。
4）每個發現服務客觀下線的sentinel，都會要求其他sentinel將自己設置成領頭。
5）當一個sentinel（源sentinel）向另一個sentinel（目sentinel）發送is-master-down-by-addr ip port current_epoch runid命令的時候，runid參數不是*，而是sentinel運行id，就表示源sentinel要求目標sentinel選舉其為領頭。
6）源sentinel會檢查目標sentinel對其要求設置成領頭的回復，如果回復的leader_runid和leader_epoch為源sentinel，表示目標sentinel同意將源sentinel設置成領頭。
7）如果某個sentinel被半數以上的sentinel設置成領頭，那麼該sentinel既為領頭。
8）如果在限定時間內，沒有選舉出領頭sentinel，暫定一段時間，再選舉。

為什麼要選領導者？
簡單來說，就是因為只能有一個sentinel節點去完成故障轉移。
sentinel is-master-down-by-addr這個命令有兩個作用，一是確認下線判定，二是進行領導者選舉。
選舉過程：
1）每個做主觀下線的sentinel節點向其他sentinel節點發送上面那條命令，要求將它設置為領導者。
2）收到命令的sentinel節點如果還沒有同意過其他的sentinel發送的命令（還未投過票），那麼就會同意，否則拒絕。
3）如果該sentinel節點發現自己的票數已經過半且達到了quorum的值，就會成為領導者
4）如果這個過程出現多個sentinel成為領導者，則會等待一段時間重新選舉。

Redis Sentinel的主從切換方案
Redis 2.8版開始正式提供名為Sentinel的主從切換方案，通俗的來講，Sentinel可以用來管理多個Redis服務器實例，可以實現一個功能上實現HA的集群，Sentinel主要負責三個方面的任務：
1）監控（Monitoring）： Sentinel 會不斷地檢查你的主服務器和從服務器是否運作正常。
2）提醒（Notification）： 當被監控的某個 Redis 服務器出現問題時， Sentinel 可以通過 API 向管理員或者其他應用程序發送通知。
3）自動故障遷移（Automatic failover）： 當一個主服務器不能正常工作時， Sentinel 會開始一次自動故障遷移操作， 它會將失效主服務器的其中一個從服務器升級為新的主服務器， 並讓失效主服務器的其他從服務器改為複製新的主服務器； 當客戶端試圖連接失效的主服務器時， 集群也會向客戶端返回新主服務器的地址， 使得集群可以使用新主服務器代替失效服務器。

Redis Sentinel 是一個分佈式系統， 可以在一個架構中運行多個 Sentinel 進程（progress）， 這些進程使用流言協議（gossip protocols)來接收關於主服務器是否下線的信息， 並使用投票協議（agreement protocols）來決定是否執行自動故障遷移， 以及選擇哪個從服務器作為新的主服務器。
一個簡單的主從結構加sentinel集群的架構圖如下：

上圖是一主一從節點，加上兩個部署了sentinel的集群，sentinel集群之間會互相通信，溝通交流redis節點的狀態，做出相應的判斷並進行處理，這裡的主觀下線狀態和客觀下線狀態是比較重要的狀態，它們決定了是否進行故障轉移
可以 通過訂閱指定的頻道信息，當服務器出現故障得時候通知管理員
客戶端可以將 Sentinel 看作是一個只提供了訂閱功能的 Redis 服務器，你不可以使用 PUBLISH 命令向這個服務器發送信息，但你可以用 SUBSCRIBE 命令或者 PSUBSCRIBE 命令， 通過訂閱給定的頻道來獲取相應的事件提醒。 一個頻道能夠接收和這個頻道的名字相同的事件。 比如說， 名為 +sdown 的頻道就可以接收所有實例進入主觀下線（SDOWN）狀態的事件。

個人認為，Sentinel實現的最主要的一個功能就是能做到自動故障遷移，即當某一個master掛了的時候，可以自動的將某一個slave提升為新的master，且原master的所有slave也都自動的將自己的master改為新提升的master，這樣我們的程序的可用性大大提高了。只要redis安裝完成，Sentinel就安裝完成了，Sentinel集成在redis里了。

Sentinel支持集群（可以部署在多台機器上，也可以在一台物理機上通過多端口實現偽集群部署）
很顯然，只使用單個sentinel進程來監控redis集群是不可靠的，當sentinel進程宕掉後(sentinel本身也有單點問題，single-point-of-failure)整個集群系統將無法按照預期的方式運行。所以有必要將sentinel集群，這樣有幾個好處：
1）即使有一些sentinel進程宕掉了，依然可以進行redis集群的主備切換；
2）如果只有一個sentinel進程，如果這個進程運行出錯，或者是網絡堵塞，那麼將無法實現redis集群的主備切換（單點問題）;
3）如果有多個sentinel，redis的客戶端可以隨意地連接任意一個sentinel來獲得關於redis集群中的信息。本博主配置好基於sentinel模式的Redis集群環境（主從複製、讀寫分離、主從切換）虛擬機下載，鏈接：https://pan.baidu.com/s/1t1DzlhiBFzlDqJkmzNj83Q
提取碼：y26r 下載後，用Vmware Workstation打開就可以使用

sentinel集群注意事項
1）只有Sentinel 集群中大多數服務器認定master主觀下線時master才會被認定為客觀下線，才可以進行故障遷移，也就是說，即使不管我們在sentinel monitor中設置的數是多少，就算是滿足了該值，只要達不到大多數，就不會發生故障遷移。
2）官方建議sentinel至少部署三台，且分佈在不同機器。這裡主要考慮到sentinel的可用性，假如我們只部署了兩台sentinel，且quorum設置為1，也可以實現自動故障遷移，但假如其中一台sentinel掛了，就永遠不會觸發自動故障遷移，因為永遠達不到大多數sentinel認定master主觀下線了。
3）sentinel monitor配置中的master IP盡量不要寫127.0.0.1或localhost，因為客戶端，如jedis獲取master是根據這個獲取的，若這樣配置，jedis獲取的ip則是127.0.0.1，這樣就可能導致程序連接不上master
4）當sentinel 啟動後會自動的修改sentinel.conf文件，如已發現的master的slave信息，和集群中其它sentinel 的信息等,這樣即使重啟sentinel也能保持原來的狀態。注意，當集群服務器調整時，如更換sentinel的機器，或者新配置一個sentinel，請不要直接複製原來運行過得sentinel配置文件，因為其裏面自動生成了以上說的那些信息，我們應該複製一個新的配置文件或者把自動生成的信息給刪掉。
5）當發生故障遷移的時候，master的變更記錄與slave更換master的修改會自動同步到redis的配置文件，這樣即使重啟redis也能保持變更後的狀態。

每個 Sentinel 都需要定期執行的任務
每個 Sentinel 以每秒鐘一次的頻率向它所知的主服務器、從服務器以及其他 Sentinel 實例發送一個 PING 命令。
如果一個實例（instance）距離最後一次有效回復 PING 命令的時間超過 down-after-milliseconds 選項所指定的值， 那麼這個實例會被 Sentinel 標記為主觀下線。 一個有效回復可以是： +PONG 、 -LOADING 或者 -MASTERDOWN 。
如果一個主服務器被標記為主觀下線， 那麼正在監視這個主服務器的所有 Sentinel 要以每秒一次的頻率確認主服務器的確進入了主觀下線狀態。
如果一個主服務器被標記為主觀下線， 並且有足夠數量的 Sentinel （至少要達到配置文件指定的數量）在指定的時間範圍內同意這一判斷， 那麼這個主服務器被標記為客觀下線。
在一般情況下， 每個 Sentinel 會以每 10 秒一次的頻率向它已知的所有主服務器和從服務器發送 INFO 命令。 當一個主服務器被 Sentinel 標記為客觀下線時， Sentinel 向下線主服務器的所有從服務器發送 INFO 命令的頻率會從 10 秒一次改為每秒一次。
當沒有足夠數量的 Sentinel 同意主服務器已經下線， 主服務器的客觀下線狀態就會被移除。 當主服務器重新向 Sentinel 的PING 命令返回有效回復時， 主服務器的主管下線狀態就會被移除。

Sentinel之間和Slaves之間的自動發現機制
雖然sentinel集群中各個sentinel都互相連接彼此來檢查對方的可用性以及互相發送消息。但是你不用在任何一個sentinel配置任何其它的sentinel的節點。因為sentinel利用了master的發佈/訂閱機制去自動發現其它也監控了統一master的sentinel節點。
通過向名為__sentinel__:hello的管道中發送消息來實現。
同樣，你也不需要在sentinel中配置某個master的所有slave的地址，sentinel會通過詢問master來得到這些slave的地址的。
每個sentinel通過向每個master和slave的發佈/訂閱頻道__sentinel__:hello每秒發送一次消息，來宣布它的存在。
每個sentinel也訂閱了每個master和slave的頻道__sentinel__:hello的內容，來發現未知的sentinel，當檢測到了新的sentinel，則將其加入到自身維護的master監控列表中。
每個sentinel發送的消息中也包含了其當前維護的最新的master配置。如果某個sentinel發現
自己的配置版本低於接收到的配置版本，則會用新的配置更新自己的master配置。
在為一個master添加一個新的sentinel前，sentinel總是檢查是否已經有sentinel與新的sentinel的進程號或者是地址是一樣的。如果是那樣，這個sentinel將會被刪除，而把新的sentinel添加上去。

sentinel和redis身份驗證
當一個master配置為需要密碼才能連接時，客戶端和slave在連接時都需要提供密碼。
master通過requirepass設置自身的密碼，不提供密碼無法連接到這個master。
slave通過masterauth來設置訪問master時的密碼。
但是當使用了sentinel時，由於一個master可能會變成一個slave，一個slave也可能會變成master，所以需要同時設置上述兩個配置項。

Sentinel API
在默認情況下， Sentinel 使用 TCP 端口 26379 （普通 Redis 服務器使用的是 6379 ）。Sentinel 接受 Redis 協議格式的命令請求， 所以你可以使用 redis-cli 或者任何其他 Redis 客戶端來與 Sentinel 進行通訊。有兩種方式可以和 Sentinel 進行通訊：
1）是通過直接發送命令來查詢被監視 Redis 服務器的當前狀態， 以及 Sentinel 所知道的關於其他 Sentinel 的信息， 諸如此類。
2）是使用發佈與訂閱功能， 通過接收 Sentinel 發送的通知： 當執行故障轉移操作， 或者某個被監視的服務器被判斷為主觀下線或者客觀下線時， Sentinel 就會發送相應的信息。

本博主配置好基於sentinel模式的Redis集群環境（主從複製、讀寫分離、主從切換）虛擬機下載，鏈接：https://pan.baidu.com/s/1t1DzlhiBFzlDqJkmzNj83Q
提取碼：y26r 下載後，用Vmware Workstation打開就可以使用