Redis集群：哨兵（Sentinel）
Redis Sentinel機制與用法說明(哨兵模式)
?
1、主Redis與各個從Redis之間能夠實現高可用(監控、自動故障遷移等)，這個委托給redis-sentinel來實現。?
2、業務代碼中為分散redis服務的壓力，全部寫操作走主庫，部分讀操作需要走從服務器的業務需求。(就目前jedis 2.6.2版本中的JedisSentinelPool做不到這點)?
3、對多個Master-Slaves組成的高可用單元做sharding集群?
概述
一、sentinel介紹
RedisSentinel?
Sentinel(哨兵)是用于監控redis集群中Master狀態的工具，其已經被集成在redis2.4+的版本中
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工作方式：?
1)：每個Sentinel以每秒鐘一次的頻率向它所知的Master，Slave以及其他 Sentinel 實例發送一個 PING 命令?
2)：如果一個實例（instance）距離最后一次有效回復 PING 命令的時間超過 down-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 的主觀下線狀態就會被移除。
主觀下線和客觀下線?
主觀下線：SubjectivelyDown，簡稱 SDOWN，指的是當前 Sentinel 實例對某個redis服務器做出的下線判斷。?
客觀下線：ObjectivelyDown，簡稱 ODOWN，指的是多個 Sentinel 實例在對Master Server做出 SDOWN 判斷，并且通過 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的Master Server下線判斷，然后開啟failover.
通俗來講就是：?
redis的sentinel系統用來管理多個redis服務器，可以實現一個功能上實現HA的集群。該系統主要執行三個任務：?
①監控（ Monitoring ）：Redis Sentinel實時監控主服務器和從服務器運行狀態。?
②提醒（notification）：當被監控的某個Redis 服務器出現問題時， Redis Sentinel 可以向系統管理員發送通知，也可以通過API 向其他程序發送通知?
一個簡單的主從結構加sentinel集群的架構圖如下：?
?
上圖是一主一從節點，加上兩個部署了sentinel的集群，sentinel集群之間會互相通信，溝通交流redis節點的狀態，做出相應的判斷并進行處理，這里的主觀下線狀態和客觀下線狀態是比較重要的狀態，它們決定了是否進行故障轉移?
可以通過訂閱指定的頻道信息，當服務器出現故障得時候通知管理員?
客戶端可以將 Sentinel 看作是一個只提供了訂閱功能的Redis 服務器，你不可以使用 PUBLISH 命令向這個服務器發送信息，但你可以用 SUBSCRIBE 命令或者PSUBSCRIBE 命令，通過訂閱給定的頻道來獲取相應的事件提醒。?
一個頻道能夠接收和這個頻道的名字相同的事件。比如說，名為+sdown 的頻道就可以接收所有實例進入主觀下線（SDOWN）狀態的事件。
概述
Redis-Sentinel是Redis官方推薦的高可用性(HA)解決方案，當用Redis做Master-slave的高可用方案時，假如master宕機了，Redis本身(包括它的很多客戶端)都沒有實現自動進行主備切換，而Redis-sentinel本身也是一個獨立運行的進程，它能監控多個master-slave集群，發現master宕機后能進行自動切換。
它的主要功能有以下幾點
·?????不時地監控redis是否按照預期良好地運行;
·?????如果發現某個redis節點運行出現狀況，能夠通知另外一個進程(例如它的客戶端);
·?????能夠進行自動切換。當一個master節點不可用時，能夠選舉出master的多個slave(如果有超過一個slave的話)中的一個來作為新的master,其它的slave節點會將它所追隨的master的地址改為被提升為master的slave的新地址。
Sentinel支持集群
很顯然，只使用單個sentinel進程來監控redis集群是不可靠的，當sentinel進程宕掉后(sentinel本身也有單點問題，single-point-of-failure)整個集群系統將無法按照預期的方式運行。所以有必要將sentinel集群，這樣有幾個好處：
·?????即使有一些sentinel進程宕掉了，依然可以進行redis集群的主備切換；
·?????如果只有一個sentinel進程，如果這個進程運行出錯，或者是網絡堵塞，那么將無法實現redis集群的主備切換（單點問題）;
·?????如果有多個sentinel，redis的客戶端可以隨意地連接任意一個sentinel來獲得關于redis集群中的信息。
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
運行sentinel有兩種方式：
·?????第一種
redis-sentinel /path/to/sentinel.conf
·?????第二種
redis-server /path/to/sentinel.conf?--sentinel
以上兩種方式，都必須指定一個sentinel的配置文件sentinel.conf，如果不指定，將無法啟動sentinel。sentinel默認監聽26379端口，所以運行前必須確定該端口沒有被別的進程占用。
Sentinel的配置
Redis源碼包中包含了一個sentinel.conf文件作為sentinel的配置文件，配置文件自帶了關于各個配置項的解釋。典型的配置項如下所示：
?
sentinel monitormymaster 127.0.0.163792
sentineldown-after-milliseconds mymaster 60000
sentinelfailover-timeout mymaster 180000
sentinelparallel-syncs mymaster 1
?
sentinel monitorresque 192.168.1.363804
sentineldown-after-milliseconds resque 10000
sentinelfailover-timeout resque 180000
sentinelparallel-syncs resque 5
?
上面的配置項配置了兩個名字分別為mymaster和resque的master，配置文件只需要配置master的信息就好啦，不用配置slave的信息，因為slave能夠被自動檢測到(master節點會有關于slave的消息)。需要注意的是，配置文件在sentinel運行期間是會被動態修改的，例如當發生主備切換時候，配置文件中的master會被修改為另外一個slave。這樣，之后sentinel如果重啟時，就可以根據這個配置來恢復其之前所監控的redis集群的狀態。
接下來我們將一行一行地解釋上面的配置項：
?sentinel monitormymaster 127.0.0.1 6379 2
這一行代表sentinel監控的master的名字叫做mymaster,地址為127.0.0.1:6379，行尾最后的一個2代表什么意思呢？我們知道，網絡是不可靠的，有時候一個sentinel會因為網絡堵塞而誤以為一個master redis已經死掉了，當sentinel集群式，解決這個問題的方法就變得很簡單，只需要多個sentinel互相溝通來確認某個master是否真的死了，這個2代表，當集群中有2個sentinel認為master死了時，才能真正認為該master已經不可用了。（sentinel集群中各個sentinel也有互相通信，通過gossip協議）。
除了第一行配置，我們發現剩下的配置都有一個統一的格式:
sentinel<option_name> <master_name> <option_value>
接下來我們根據上面格式中的option_name一個一個來解釋這些配置項：
·?????down-after-milliseconds
sentinel會向master發送心跳PING來確認master是否存活，如果master在“一定時間范圍”內不回應PONG?或者是回復了一個錯誤消息，那么這個sentinel會主觀地(單方面地)認為這個master已經不可用了(subjectively down, 也簡稱為SDOWN)。而這個down-after-milliseconds就是用來指定這個“一定時間范圍”的，單位是毫秒。
不過需要注意的是，這個時候sentinel并不會馬上進行failover主備切換，這個sentinel還需要參考sentinel集群中其他sentinel的意見，如果超過某個數量的sentinel也主觀地認為該master死了，那么這個master就會被客觀地(注意哦，這次不是主觀，是客觀，與剛才的subjectivelydown相對，這次是objectively down，簡稱為ODOWN)認為已經死了。需要一起做出決定的sentinel數量在上一條配置中進行配置。
·?????parallel-syncs
在發生failover主備切換時，這個選項指定了最多可以有多少個slave同時對新的master進行同步，這個數字越小，完成failover所需的時間就越長，但是如果這個數字越大，就意味著越多的slave因為replication而不可用。可以通過將這個值設為 1 來保證每次只有一個slave處于不能處理命令請求的狀態。
其他配置項在sentinel.conf中都有很詳細的解釋。
所有的配置都可以在運行時用命令SENTINEL SET command動態修改。
Sentinel的“仲裁會”
前面我們談到，當一個master被sentinel集群監控時，需要為它指定一個參數，這個參數指定了當需要判決master為不可用，并且進行failover（主備切換）時，所需要的sentinel數量，本文中我們暫時稱這個參數為票數(投票給master)
不過，當failover主備切換真正被觸發后，failover并不會馬上進行，還需要sentinel中的大多數sentinel授權后才可以進行failover。
當ODOWN（主觀下線后，Sentinel投票授權后成為ODOWN狀態------客觀授權）時，failover被觸發。failover一旦被觸發，嘗試去進行failover的sentinel會去獲得“大多數”sentinel的授權（如果票數比大多數還要大的時候，則詢問更多的sentinel)則授權的票數要比認為它DIE的票數多
這個區別看起來很微妙，但是很容易理解和使用。
例如，集群中有5個sentinel，票數被設置為2，當2個sentinel認為一個master已經不可用了以后，將會觸發failover，但是，進行failover的那個sentinel必須先獲得至少3個sentinel的授權才可以實行failover。
如果票數被設置為5，要達到ODOWN狀態，必須所有5個sentinel都主觀認為master為不可用，要進行failover，那么得獲得所有5個sentinel的授權。
配置版本號
為什么要先獲得大多數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并發送SLAVEOFNO ONE后，即使其它的slave還沒針對新master重新配置自己，failover也被認為是成功了的，然后所有sentinels將會發布新的配置信息。
新配在集群中相互傳播的方式，就是為什么我們需要當一個sentinel進行failover時必須被授權一個版本號的原因。
每個sentinel使用##發布/訂閱##的方式持續地傳播master的配置版本信息，配置傳播的##發布/訂閱##管道是：__sentinel__:hello。
因為每一個配置都有一個版本號，所以以版本號最大的那個為標準。
舉個栗子：假設有一個名為mymaster的地址為192.168.1.50:6379。一開始，集群中所有的sentinel都知道這個地址，于是為mymaster的配置打上版本號1。一段時候后mymaster死了，有一個sentinel被授權用版本號2對其進行failover。如果failover成功了，假設地址改為了192.168.1.51:9000，此時配置的版本號為2，進行failover的sentinel會將新配置廣播給其他的sentinel，由于其他sentinel維護的版本號為1，發現新配置的版本號為2時，版本號變大了，說明配置更新了，于是就會采用最新的版本號為2的配置。
這意味著sentinel集群保證了第二種活躍性：一個能夠互相通信的sentinel集群最終會采用版本號最高且相同的配置。
SDOWN和ODOWN的更多細節
sentinel對于不可用有兩種不同的看法，一個叫主觀不可用(SDOWN),另外一個叫客觀不可用(ODOWN)。SDOWN是sentinel自己主觀上檢測到的關于master的狀態，ODOWN需要一定數量的sentinel達成一致意見才能認為一個master客觀上已經宕掉，各個sentinel之間通過命令SENTINELis_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之間和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添加上去。（即每個master都有相關的其他sentinel和slave的信息，每個sentinel都通過了發布/訂閱頻道取得了master相關的sentinel和slave信息）
網絡隔離時的一致性
redis sentinel集群的配置的一致性模型為最終一致性，集群中每個sentinel最終都會采用最高版本的配置。然而，在實際的應用環境中，有三個不同的角色會與sentinel打交道：
·?????Redis實例.
·?????Sentinel實例.
·?????客戶端.
為了考察整個系統的行為我們必須同時考慮到這三個角色。
下面有個簡單的例子，有三個主機，每個主機分別運行一個redis和一個sentinel:
在這個系統中，初始狀態下redis3是master, redis1和redis2是slave。之后redis3所在的主機網絡不可用了，sentinel1和sentinel2啟動了failover并把redis1選舉為master。
Sentinel集群的特性保證了sentinel1和sentinel2得到了關于master的最新配置。但是sentinel3依然持著的是就的配置，因為它與外界隔離了。
當網絡恢復以后，我們知道sentinel3將會更新它的配置。但是，如果客戶端所連接的master被網絡隔離，會發生什么呢？
客戶端將依然可以向redis3寫數據，但是當網絡恢復后，redis3就會變成redis的一個slave，那么，在網絡隔離期間，客戶端向redis3寫的數據將會丟失。
也許你不會希望這個場景發生：
·?????如果你把redis當做緩存來使用，那么你也許能容忍這部分數據的丟失。
·?????但如果你把redis當做一個存儲系統來使用，你也許就無法容忍這部分數據的丟失了。
因為redis采用的是異步復制，在這樣的場景下，沒有辦法避免數據的丟失。然而，你可以通過以下配置來配置redis3和redis1，使得數據不會丟失。
min-slaves-to-write 1
min-slaves-max-lag10
通過上面的配置，當一個redis是master時，如果它不能向至少一個slave寫數據(上面的min-slaves-to-write指定了slave的數量)，它將會拒絕接受客戶端的寫請求。由于復制是異步的，master無法向slave寫數據意味著slave要么斷開連接了，要么不在指定時間內向master發送同步數據的請求了(上面的min-slaves-max-lag指定了這個時間)。
Sentinel狀態持久化
snetinel的狀態會被持久化地寫入sentinel的配置文件中。每次當收到一個新的配置時，或者新創建一個配置時，配置會被持久化到硬盤中，并帶上配置的版本戳。這意味著，可以安全的停止和重啟sentinel進程。
無failover時的配置糾正
即使當前沒有failover正在進行，sentinel依然會使用當前配置去設置監控的master。特別是：
·?????根據最新配置確認為slaves的節點卻聲稱自己是master(上文例子中被網絡隔離后的的redis3)，這時它們會被重新配置為當前master的slave。
·?????如果slaves連接了一個錯誤的master，將會被改正過來，連接到正確的master。
Slave選舉與優先級
當一個sentinel準備好了要進行failover，并且收到了其他sentinel的授權，那么就需要選舉出一個合適的slave來做為新的master。
slave的選舉主要會評估slave的以下幾個方面：
·?????與master斷開連接的次數
·?????Slave的優先級
·?????數據復制的下標(用來評估slave當前擁有多少master的數據)
·?????進程ID
如果一個slave與master失去聯系超過10次，并且每次都超過了配置的最大失聯時間(down-after-milliseconds)，如果sentinel在進行failover時發現slave失聯，那么這個slave就會被sentinel認為不適合用來做新master的。
更嚴格的定義是，如果一個slave持續斷開連接的時間超過
(down-after-milliseconds*?10) + milliseconds_since_master_is_in_SDOWN_state
就會被認為失去選舉資格。（超時，或者斷開次數太多）
符合上述條件的slave才會被列入master候選人列表，并根據以下順序來進行排序：
1.????????????sentinel首先會根據slaves的優先級來進行排序，優先級越小排名越靠前。
2.????????????如果優先級相同，則查看復制的下標，哪個從master接收的復制數據多，哪個就靠前。
3.????????????如果優先級和下標都相同，就選擇進程ID較小的那個。
一個redis無論是master還是slave，都必須在配置中指定一個slave優先級。要注意到master也是有可能通過failover變成slave的。
如果一個redis的slave優先級配置為0，那么它將永遠不會被選為master。但是它依然會從master哪里復制數據。
Sentinel和Redis身份驗證
當一個master配置為需要密碼才能連接時，客戶端和slave在連接時都需要提供密碼。
master通過requirepass設置自身的密碼，不提供密碼無法連接到這個master。
slave通過masterauth來設置訪問master時的密碼。
但是當使用了sentinel時，由于一個master可能會變成一個slave，一個slave也可能會變成master，所以需要同時設置上述兩個配置項。
Sentinel API
Sentinel默認運行在26379端口上，sentinel支持redis協議，所以可以使用redis-cli客戶端或者其他可用的客戶端來與sentinel通信。
有兩種方式能夠與sentinel通信：
·?????一種是直接使用客戶端向它發消息
·?????另外一種是使用發布/訂閱模式來訂閱sentinel事件，比如說failover，或者某個redis實例運行出錯，等等。?
Sentinel命令
sentinel支持的合法命令如下：
·?????PING?sentinel回復PONG.
·?????SENTINELmasters?顯示被監控的所有master以及它們的狀態.
·?????SENTINELmaster <master name>?顯示指定master的信息和狀態；
·?????SENTINELslaves <master name>?顯示指定master的所有slave以及它們的狀態；
·?????SENTINELget-master-addr-by-name <master name>?返回指定master的ip和端口，如果正在進行failover或者failover已經完成，將會顯示被提升為master的slave的ip和端口。
·?????SENTINELreset <pattern>?重置名字匹配該正則表達式的所有的master的狀態信息，清楚其之前的狀態信息，以及slaves信息。
·?????SENTINELfailover <master name>?強制sentinel執行failover，并且不需要得到其他sentinel的同意。但是failover后會將最新的配置發送給其他sentinel。
動態修改Sentinel配置
從redis2.8.4開始，sentinel提供了一組API用來添加，刪除，修改master的配置。
需要注意的是，如果你通過API修改了一個sentinel的配置，sentinel不會把修改的配置告訴其他sentinel。你需要自己手動地對多個sentinel發送修改配置的命令。
以下是一些修改sentinel配置的命令：
·?????SENTINELMONITOR <name> <ip> <port> <quorum>?這個命令告訴sentinel去監聽一個新的master
·?????SENTINELREMOVE <name>?命令sentinel放棄對某個master的監聽
·?????SENTINELSET <name> <option> <value>?這個命令很像Redis的CONFIGSET命令，用來改變指定master的配置。支持多個<option><value>。例如以下實例：
·?????SENTINELSET objects-cache-master down-after-milliseconds 1000
只要是配置文件中存在的配置項，都可以用SENTINEL SET命令來設置。這個還可以用來設置master的屬性，比如說quorum(票數)，而不需要先刪除master，再重新添加master。例如：
SENTINEL?SET?objects-cache-master?quorum?5
增加或刪除Sentinel
由于有sentinel自動發現機制，所以添加一個sentinel到你的集群中非常容易，你所需要做的只是監控到某個Master上，然后新添加的sentinel就能獲得其他sentinel的信息以及master所有的slaves。
如果你需要添加多個sentinel，建議你一個接著一個添加，這樣可以預防網絡隔離帶來的問題。你可以每個30秒添加一個sentinel。最后你可以用SENTINEL MASTER mastername來檢查一下是否所有的sentinel都已經監控到了master。
刪除一個sentinel顯得有點復雜：因為sentinel永遠不會刪除一個已經存在過的sentinel，即使它已經與組織失去聯系很久了。
要想刪除一個sentinel，應該遵循如下步驟：
1.????????????停止所要刪除的sentinel
2.????????????發送一個SENTINEL RESET *?命令給所有其它的sentinel實例，如果你想要重置指定master上面的sentinel，只需要把*號改為特定的名字，注意，需要一個接一個發，每次發送的間隔不低于30秒。
3.????????????檢查一下所有的sentinels是否都有一致的當前sentinel數。使用SENTINELMASTER mastername?來查詢。
刪除舊master或者不可達slave
sentinel永遠會記錄好一個Master的slaves，即使slave已經與組織失聯好久了。這是很有用的，因為sentinel集群必須有能力把一個恢復可用的slave進行重新配置。
并且，failover后，失效的master將會被標記為新master的一個slave，這樣的話，當它變得可用時，就會從新master上復制數據。
然后，有時候你想要永久地刪除掉一個slave(有可能它曾經是個master)，你只需要發送一個SENTINEL RESET master命令給所有的sentinels，它們將會更新列表里能夠正確地復制master數據的slave。
發布/訂閱
客戶端可以向一個sentinel發送訂閱某個頻道的事件的命令，當有特定的事件發生時，sentinel會通知所有訂閱的客戶端。需要注意的是客戶端只能訂閱，不能發布。
訂閱頻道的名字與事件的名字一致。例如，頻道名為sdown?將會發布所有與SDOWN相關的消息給訂閱者。
如果想要訂閱所有消息，只需簡單地使用PSUBSCRIBE *
以下是所有你可以收到的消息的消息格式，如果你訂閱了所有消息的話。第一個單詞是頻道的名字，其它是數據的格式。
注意：以下的instance details的格式是：
<instance-type> <name> <ip> <port> @<master-name> <master-ip> <master-port>
如果這個redis實例是一個master，那么@之后的消息就不會顯示。
?
? +reset-master <instance details> -- 當master被重置時.
??? +slave <instance details> -- 當檢測到一個slave并添加進slave列表時.
??? +failover-state-reconf-slaves <instancedetails> -- Failover狀態變為reconf-slaves狀態時
??? +failover-detected <instance details>-- 當failover發生時
??? +slave-reconf-sent <instance details>-- sentinel發送SLAVEOF命令把它重新配置時
??? +slave-reconf-inprog <instancedetails> -- slave被重新配置為另外一個master的slave，但數據復制還未發生時。
??? +slave-reconf-done <instance details>-- slave被重新配置為另外一個master的slave并且數據復制已經與master同步時。
??? -dup-sentinel <instance details> -- 刪除指定master上的冗余sentinel時(當一個sentinel重新啟動時，可能會發生這個事件).
??? +sentinel <instance details> -- 當master增加了一個sentinel時。
??? +sdown <instance details> -- 進入SDOWN狀態時;
??? -sdown <instance details> -- 離開SDOWN狀態時。
??? +odown <instance details> -- 進入ODOWN狀態時。
??? -odown <instance details> -- 離開ODOWN狀態時。
??? +new-epoch <instance details> -- 當前配置版本被更新時。
??? +try-failover <instance details> -- 達到failover條件，正等待其他sentinel的選舉。
??? +elected-leader <instance details> -- 被選舉為去執行failover的時候。
??? +failover-state-select-slave<instance details> -- 開始要選擇一個slave當選新master時。
??? no-good-slave <instance details> -- 沒有合適的slave來擔當新master
??? selected-slave <instance details> -- 找到了一個適合的slave來擔當新master
??? failover-state-send-slaveof-noone<instance details> -- 當把選擇為新master的slave的身份進行切換的時候。
??? failover-end-for-timeout <instance details> -- failover由于超時而失敗時。
??? failover-end<instance details> --failover成功完成時。
??? switch-master <master name> <oldip><oldport> <newip> <newport> -- 當master的地址發生變化時。通常這是客戶端最感興趣的消息了。
??? +tilt -- 進入Tilt模式。
??? -tilt -- 退出Tilt模式。
?
TILT 模式
redis sentinel非常依賴系統時間，例如它會使用系統時間來判斷一個PING回復用了多久的時間。
然而，假如系統時間被修改了，或者是系統十分繁忙，或者是進程堵塞了，sentinel可能會出現運行不正常的情況。
當系統的穩定性下降時，TILT模式是sentinel可以進入的一種的保護模式。當進入TILT模式時，sentinel會繼續監控工作，但是它不會有任何其他動作，它也不會去回應is-master-down-by-addr這樣的命令了，因為它在TILT模式下，檢測失效節點的能力已經變得讓人不可信任了。
如果系統恢復正常，持續30秒鐘，sentinel就會退出TITL模式。
-BUSY狀態
注意：該功能還未實現。
當一個腳本的運行時間超過配置的運行時間時，sentinel會返回一個-BUSY 錯誤信號。如果這件事發生在觸發一個failover之前，sentinel將會發送一個SCRIPT KILL命令，如果script是只讀的話，就能成功執行。
總結
以上是生活随笔為你收集整理的Redis集群：哨兵（Sentinel）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： JAVA: final 修饰符
- 下一篇： Redis集群：redis cluste