Redis Sentinel 文檔說明

1、Redis Sentinel 文檔說明Redis Sentinel 的設(shè)計(jì)目標(biāo)是用來協(xié)助管理Redis實(shí)例的系統(tǒng)，它通常執(zhí)行下面的4類任務(wù)： 監(jiān)控，Sentinel會(huì)持續(xù)的檢測(cè)master和slave的實(shí)例是否像期望的方式工作。 通知，Sentinel可以通過一個(gè)API，通知系統(tǒng)管理員，或計(jì)算機(jī)上的其他程序，它監(jiān)控的redis實(shí)例中那些事情出錯(cuò)了。 自動(dòng)的錯(cuò)誤恢復(fù)，如果一個(gè)master不能像期望的那樣正常工作，Sentinel可以啟動(dòng)一個(gè)錯(cuò)誤恢復(fù)的處理過程， 將一個(gè)slave升級(jí)成為master，并使其他的slave成為新的master的slave，應(yīng)用使用Redis server獲取新mas

2、ter位置的通知。 配置信息的獲取，Sentinel會(huì)作為面向客戶端的服務(wù)的一個(gè)發(fā)現(xiàn)的源頭：客戶端會(huì)通過與Sentinels連接，來獲取當(dāng)前工作的Redis master 的位置。如果經(jīng)歷了錯(cuò)誤恢復(fù)，Sentinels將會(huì)報(bào)告新的master的地址。Sentinel的分布式本質(zhì)（Distributed nature of Sentinel）Redis Sentinel是一個(gè)可分布的系統(tǒng)，這意味著通常你會(huì)在你的基礎(chǔ)規(guī)劃中選擇運(yùn)行多個(gè)Sentinel進(jìn)程，而這些進(jìn)程會(huì)使用gossip protocols來理解一個(gè)master是否下線，并使用agreement protocols來獲取執(zhí)行錯(cuò)誤恢復(fù)的

3、授權(quán)，或賦予一個(gè)新配置新的版本。分布式系統(tǒng)具有安全（safety）和活動(dòng)（liveness）的特性，如果想能使用好Redis Sentinel，你應(yīng)該理解Sentinel是如果作為一個(gè)分布式系統(tǒng)工作的。這些使Sentinel與單進(jìn)程的程序相比，會(huì)更復(fù)雜并更具有優(yōu)勢(shì)，如： 一個(gè)Sentinels的群集，即便其中一部分Sentinels失效，仍然可以完成一個(gè)master的故障恢復(fù)。 如果一個(gè)Sentinel工作不正常，或連接不上，不會(huì)得到其它的Sentinels的授權(quán)，也就不可能做故障恢復(fù)的工作。 客戶端可以連接任意的Sentinel來獲取master的配置信息。獲取Sentinel（Obtain

4、ing Sentinel）Sentinel當(dāng)前是Redis source code的Github上的一個(gè)unstable的分支，不過自Redis 2.8開始，會(huì)作為不定進(jìn)入到Redis的發(fā)行版本。使用Sentinel最簡單的方式是下載Redis 2.8之后的最新版本，或編譯Github上的最新的unstable的分支。注意：即便你是在使用Redis 2.6，你也應(yīng)該使用Redis 2.8中的Sentinel。運(yùn)行Sentinel（Running Sentinel）如果你使用的 redis-sentinel 可執(zhí)行程序（或者是一個(gè)到 redis-server 可執(zhí)行程序的符號(hào)鏈接)， 你可以使用

5、下面的命令運(yùn)行Sentinel：redis-sentinel /path/to/sentinel.conf另外，你可以直接使用 redis-server 可執(zhí)行程序使用 Sentinel 模式來啟動(dòng)：redis-server /path/to/sentinel.conf -sentinel這兩種方式?jīng)]什么區(qū)別。此外，運(yùn)行 Sentinel 被強(qiáng)制要求使用配置文件，因?yàn)檫@個(gè)文件會(huì)被 Sentinel 用來保存它的當(dāng)前狀態(tài)，以便可以在 Sentinel 重新啟動(dòng)的情況下可以恢復(fù) Sentinel 的狀態(tài)。如果沒有配置文件，或配置文件不能寫入，Sentinel 會(huì)拒絕啟動(dòng)。Sentinel默認(rèn)監(jiān)聽在

6、26379的TCP端口，所以你的服務(wù)器必須開放 26379 端口，這樣 Sentinel 才能接收來自其他IP的 Sentinel 的實(shí)例的連接。否則 Sentinels 將無法會(huì)話，也無法贊同應(yīng)該做的事情，當(dāng)然也無法執(zhí)行錯(cuò)誤恢復(fù)。Sentinel的配置（Configuring Sentinel）在 Redis 的發(fā)布的源代碼中，包含一個(gè)sentinel.conf 的文件，是一個(gè)自描述的Sentinel的配置文件的例子。一般，一個(gè)典型的最小化的配置看起來應(yīng)該是下面這樣子：sentinel monitor mymaster 127.0.0.1 6379 2sentinel down-after-

7、milliseconds mymaster 60000sentinel failover-timeout mymaster 180000sentinel parallel-syncs mymaster 1sentinel monitor resque 192.168.1.3 6380 4sentinel down-after-milliseconds resque 10000sentinel failover-timeout resque 180000sentinel parallel-syncs resque 5第一行用于告知監(jiān)控的 Redis 的 master ，被命名為mymaster，

8、位于 IP 127.0.0.1，端口 6379， 并且啟動(dòng)故障恢復(fù)的sentinels的同意的數(shù)量（agreement）是2（如果同意的數(shù)量沒有達(dá)到，不會(huì)啟動(dòng)故障恢復(fù)的過程）。然而，無論 Sentinel 需要達(dá)成什么一致，Sentinel 都要求所有群集中的知道的Sentinels的主體的投票，來開始一個(gè)故障恢復(fù)和獲取一個(gè)新生代的配置用來描述故障恢復(fù)后的配置狀態(tài)。在這個(gè)例子中，法定人數(shù)（quorum）被設(shè)置為2，因此需要兩個(gè)sentinels贊同 master 已經(jīng)無法聯(lián)絡(luò)，或處于一種可以觸發(fā)故障恢復(fù)的錯(cuò)誤狀態(tài)（然而像下一個(gè)小節(jié)將看到的，觸發(fā)故障恢復(fù)僅僅啟動(dòng)還是不夠的，還需要授權(quán)）。其他的配

9、置項(xiàng)基本是下面的形式：sentinel 他們被用于下面的場景： down-after-milliseconds 是以毫秒計(jì)時(shí)的時(shí)間長度，當(dāng)一個(gè)redis的實(shí)例不能聯(lián)系上（或者是沒有應(yīng)答 PINGs 命令，或者是它返回了一個(gè)錯(cuò)誤）的時(shí)候，Sentinel 開始認(rèn)為它已經(jīng)down了。如果這持續(xù)了這個(gè)指定的時(shí)間，當(dāng)前的 Sentinel 會(huì)標(biāo)記這個(gè)redis的實(shí)例為SDOWN （subjectively down），這還不足以啟動(dòng)一個(gè)自動(dòng)的故障恢復(fù)。然而，如果足夠的 Sentinel 實(shí)例認(rèn)為這個(gè)redis實(shí)例為 SDOWN，這個(gè)redis實(shí)例會(huì)被標(biāo)記為 ODOWN（objectively down

10、）。需要贊同的Sentinel 實(shí)例數(shù)量依賴于這個(gè)master的配置的同意的數(shù)量（agreement）的配置。 parallel-syncs 設(shè)置經(jīng)過故障恢復(fù)之后，可以同時(shí)被配置為新master的slaves的數(shù)量。這個(gè)數(shù)量配置的越小，執(zhí)行故障恢復(fù)所需的時(shí)間就越長，然而如果slaves還用于提供數(shù)據(jù)服務(wù)，你可能不希望所有的slaves在同一時(shí)間都在和master同步。這樣，當(dāng)復(fù)制處理的過程中，一個(gè)slave大多會(huì)處于非阻塞的狀態(tài)。你可以通過設(shè)置這個(gè)值為1，來確保一個(gè)時(shí)間之內(nèi)，只有一個(gè)slave在同步。其他的選項(xiàng)在 Redis 的發(fā)布的源代碼中的sentinel.conf 文件中描述。所有的配置

11、參數(shù)可以在運(yùn)行期通過 SENTINEL SET 命令來修改?？?在運(yùn)行期配置Sentinel（Reconfiguring Sentinel at runtime）小節(jié)獲取更多信息。法定人數(shù)（Quorum）前面的小節(jié)說明：每個(gè)被關(guān)聯(lián)的 Sentinel 監(jiān)控的 master，會(huì)涉及到一個(gè)配置的法定人數(shù)（quorum）。它指定了判斷一個(gè)maser無法聯(lián)系或處于需要觸發(fā)故障恢復(fù)的錯(cuò)誤狀態(tài)的 所需的贊同的 Sentinel 的數(shù)量。然而，如果故障恢復(fù)的條件達(dá)到，如果確實(shí)需要執(zhí)行故障恢復(fù)，至少還需要 Sentinels 的主體的授權(quán)。讓我們把事情弄更清楚一些： 法定人數(shù)（quorum）: 是檢測(cè)到一個(gè)m

12、aster并標(biāo)記為 SDOWN 的 Sentinel 實(shí)例的數(shù)量，目標(biāo)是將一個(gè)master標(biāo)記為ODOWN。 故障恢復(fù)由 ODOWN 狀態(tài)觸發(fā)。 一旦故障恢復(fù)被觸發(fā)，這個(gè)試圖執(zhí)行故障恢復(fù)的 Sentinel 實(shí)例被強(qiáng)制獲取Sentinels主體的授權(quán)（如果 quorum 被這種成大于主體的數(shù)字，會(huì)被要求多于主體的授權(quán)）譯者注：主體理解成大多數(shù)吧，也就是多于一半就好。這種差別也許看起來很微妙，但是使用和理解上卻是很簡單。例如，如果你有5個(gè)Sentinel實(shí)例，并設(shè)置 quorum 為2，那么故障恢復(fù)在 2 個(gè) Sentinels 認(rèn)為 master down的時(shí)候就會(huì)啟動(dòng)，然而需要至少 3 個(gè)S

13、entinels授權(quán)才會(huì)真正的開始故障恢復(fù)。如果把 quorum 配置成 5，那么就需要所有的 Sentinels 認(rèn)同 master down的時(shí)候，故障恢復(fù)才會(huì)啟動(dòng)，并且需要所有的 Sentinels 授權(quán)，故障恢復(fù)才會(huì)執(zhí)行。配置的代（Configuration epochs）Sentinels要求獲取主體的授權(quán)來啟動(dòng)故障恢復(fù)是因?yàn)橐恍┲匾脑颍寒?dāng)一個(gè) Sentinel 做出了授權(quán)，他就會(huì)獲取到這個(gè)master故障恢復(fù)的唯一的配置的代（configuration epoch）。這是一個(gè)在故障恢復(fù)之后用來標(biāo)記新配置的版本的數(shù)字。因?yàn)橹黧w同意分配版本給一個(gè) Sentinel，沒有其他的 Se

14、ntinel 可以使用它。這意味著每一個(gè)故障恢復(fù)的每次配置都會(huì)有一個(gè)唯一的版本號(hào)。我們將會(huì)看到為什么這個(gè)如此重要。此外 Sentinels 有一個(gè)規(guī)則：如果如果一個(gè) Sentinel 給另外一個(gè) Sentinel 的master的故障恢復(fù)投票，它會(huì)等待這個(gè)master的故障恢復(fù)一段的時(shí)間。這個(gè)時(shí)間就是在 sentinel.conf 中配置的failover-timeout。這表示在這個(gè)期間 Sentinels 不會(huì)再對(duì)相同的master再做故障恢復(fù)，然后嘗試第一次的授權(quán)請(qǐng)求，如果失敗再試，等等。Redis Sentinel的 存活 的保證，來自Sentinels的主體的可交互性，最終體現(xiàn)在ma

15、ster的故障恢復(fù)的授權(quán)上。Redis Sentinel的 安全 的保證，來自每個(gè)Sentinel 做同一個(gè)master的故障恢復(fù)，會(huì)使用一個(gè)不同的、唯一的配置的代。配置的傳播（Configuration propagation）一旦一個(gè) Sentinel 可以成功的對(duì)一個(gè)master做故障恢復(fù)，它會(huì)開始對(duì)廣播這個(gè)新的配置，這樣其它的 Sentinels 會(huì)根據(jù)廣播的配置更新自己的信息。因?yàn)楣收匣謴?fù)被認(rèn)為是成功的，它要求 Sentinel 可以發(fā)送 SLAVEOF NO ONE 命令給選擇的 slave，并將其切換成為master。這可以通過在 master 上看 INFO 的命令的輸出就能看

16、到。在設(shè)個(gè)時(shí)間點(diǎn)，即使slaves的配置還在繼續(xù)，但這個(gè)故障恢復(fù)的過程已經(jīng)被看作是成功的，并且所有的 Sentinels 要求報(bào)告新的配置。新的配置的傳播方式是為什么每個(gè) Sentinel 被授權(quán)為一個(gè)不同版本號(hào)的原因（配置代）。每個(gè) Sentinel 會(huì)不斷的廣播它的 master 的配置的版本，使用Redis的Pub/Sub命令，在所有的master和master的所有的slaves上。同時(shí)，所有的 Sentinels 也在等待其他的 Sentinels 廣播的消息，來查看其他Sentinels 廣播的配置信息。配置信息通過 _sentinel_:hello Pub/Sub channel

17、來廣播。因?yàn)槊總€(gè)配置都有一個(gè)不同的版本號(hào)，因此更大的版本號(hào)總是會(huì)覆蓋小的版本。因此，例如，開始的時(shí)候所有的 Sentinels 認(rèn)為 mymaster 的配置中，master位于 192.168.1.50:6379。這個(gè)配置具有版本 1。過了一些時(shí)間，一個(gè) Sentinel 獲得了授權(quán)執(zhí)行了故障恢復(fù)，切換到版本 2。如果故障恢復(fù)成功，它開始廣播新配置，假設(shè)是 192.168.50:9000，帶有版本 2。所有其他Sentinel 會(huì)看到這個(gè)配置，并將其更新到他們的配置之中，因?yàn)樾碌呐渲糜懈蟮陌姹?。這意味著 Sentinel 提供了另外一個(gè)存活性的特性：一個(gè) Sentinels 的集合可以相互

18、通訊，并聚集到有更高版本、相同的配置下。基本上，如果網(wǎng)絡(luò)是分離的，每個(gè)部分都會(huì)聚集到更高的本地配置的版本下；在消除分區(qū)的特定情況下，所有Sentinel會(huì)成為一個(gè)分區(qū)，并會(huì)統(tǒng)一配置。關(guān)于SDOWN 和ODOWN的更多的細(xì)節(jié)（More details about SDOWN and ODOWN）像已經(jīng)描述過的，Redis Sentinel 有兩個(gè)不同的描述 down 的概念，一個(gè)是稱為主觀down（Subjectively Downcondition，SDOWN），是 Sentinel 實(shí)例在本地對(duì)down狀態(tài)的判斷。另外一個(gè)被稱為客觀 down （Objectively Downconditi

19、on，ODOWN），是收集了足夠 Sentinels 實(shí)例（至少是 monitored master中 quorum參數(shù)的數(shù)量） 提供了 SDOWN 的指示，并且從這些 Sentinels 使用 SENTINEL is-master-down-by-addr 命令取得反饋。簡單的看，Sentinel 給出 SDOWN 的狀態(tài)的條件，就是它在一個(gè)is-master-down-after-milliseconds 配置參數(shù)指定的時(shí)間內(nèi)沒有收到有效的 PING 請(qǐng)求的回復(fù)?？梢越邮艿?PING 的回復(fù)是下面這些： PING replied with +PONG. PING replied with

20、-LOADING error. PING replied with -MASTERDOWN error.任何其他的回復(fù)（或沒回復(fù)）認(rèn)為是無效的。注意，SDOWN 的條件是在整個(gè)配置的間隔時(shí)間內(nèi)沒有有效的回復(fù)，比如，如果間隔時(shí)間是30000 milliseconds (30 seconds)，而我們的 PING 每次都在 29 后收到回復(fù)，這個(gè)redis 實(shí)例就被看作是有效的。從 SDOWN 到 ODOWN 的切換是沒有強(qiáng)制的一致性算法的，僅是 gossip 的一個(gè)實(shí)現(xiàn)：如果一個(gè)指定的 Sentinel 在一個(gè)給定的時(shí)間范圍內(nèi)，獲得足夠數(shù)量的Sentinels的報(bào)告，聲稱 master 已經(jīng)失效

21、，就會(huì)將 master 的狀態(tài)從 SDOWN 切換到 ODOWN。如果這個(gè)認(rèn)可后來消失了，狀態(tài)標(biāo)志會(huì)被清除。像已經(jīng)闡述的，后面會(huì)執(zhí)行一個(gè)更嚴(yán)格的授權(quán)機(jī)制來正式啟動(dòng)故障恢復(fù)機(jī)制，但如果沒達(dá)到 ODOWN 狀態(tài)，不會(huì)啟動(dòng)任何故障恢復(fù)的過程。ODOWN 僅僅作用于 master。對(duì)于其它類型的 redis 實(shí)例，Sentinel 不會(huì)要求任何許可，因此對(duì)于 slaves 或其他的 sentinels 實(shí)例是不會(huì)出現(xiàn) ODOWN 的狀態(tài)的。Sentinels和Sentinels的自動(dòng)發(fā)現(xiàn)（Sentinels and Slaves auto discovery）當(dāng) Sentinels 于其它的 Sent

22、inels 相互連接以相互檢查彼此的可用性，并交換消息時(shí)，你不需要在 Sentinel 上配置其他 Sentinel 的地址，因?yàn)?Sentinel 使用 Redis 的 master 的 Pub/Sub 來發(fā)現(xiàn)其它的監(jiān)控相同 master 的 Sentinel 的位置。這是從名字為 _sentinel_:hello 的消息通道的 hello 消息中獲取的信息。類似的，你也不需要配置master有那些 slaves ，因?yàn)?Sentinel 會(huì)查詢 redis 的信息來自動(dòng)發(fā)現(xiàn)。 每個(gè) Sentinel 對(duì)每個(gè)監(jiān)控的 master 和 slave 每 2秒 發(fā)布一個(gè)消息，傳遞到其 _senti

23、nel_:hello 消息通道，通告當(dāng)前 Sentinel的IP、端口和 runid。 每個(gè) Sentinel都訂閱每個(gè)監(jiān)控的 master 和 slave 的_sentinel_:hello 消息通道，查找未知的 sentinels。如果找到新的 sentinels，它們被添加作為 master 的 sentinels 中的一員。 Hello 消息也被包含到 master 的完整的配置之中。如果一個(gè) Sentinel 擁有的配置比它接收的任何一個(gè)配置要舊，它會(huì)馬上升級(jí)到這個(gè)更新的配置。 在添加一個(gè)新的 Sentinel 到 master 之前，Sentinel會(huì)檢查 runid 或 地址（I

24、P+端口）是否重復(fù)。所有重復(fù)的 Sentinel 會(huì)被刪除，然后再添加新的Sentinel。分區(qū)后的一致性（Consistency under partitions）Redis Sentinel的配置是最終一致的，所以每個(gè)分區(qū)都會(huì)向可用的更高配置聚集。而在真實(shí)的世界中 Sentinel 有 3個(gè) 不同的角色： Redis instances. Sentinel instances. Clients.為了可以定義系統(tǒng)的行為，我們需要考慮這全部的 3個(gè)角色。下面是一個(gè)簡單的網(wǎng)絡(luò)拓?fù)?，?個(gè)節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)上有一個(gè) Redis 實(shí)例，一個(gè) Sentinel 實(shí)例： +-+ | Sentinel 1 |

25、 - Client A | Redis 1 (M) | +-+ | |+-+ | +-+| Sentinel 2 |-+- / partition / -| Sentinel 3 | - Client B| Redis 2 (S) | | Redis 3 (M)|+-+ +-+在這個(gè)體系中原本 Redis 3 是 master，Redis 1和 2 是 slaves。一個(gè)網(wǎng)絡(luò)分區(qū)出現(xiàn)，隔離了原來的 master。然后 Sentinels 1和 2啟動(dòng)了錯(cuò)誤恢復(fù)的過程，將Redis 1 升級(jí)為新的 master。Sentinel 的特性保證 Sentinel 1和 2 擁有 master 的新配

26、置。但是 Sentinel 3 還停留在舊的配置，因?yàn)樗诓煌木W(wǎng)絡(luò)分區(qū)。我們知道 Sentinel 3 在網(wǎng)絡(luò)分區(qū)消失的時(shí)候會(huì)獲取最新的配置，但是在網(wǎng)絡(luò)出現(xiàn)分區(qū)的時(shí)候如果有 clients 跟著老的 master 出現(xiàn)分區(qū)會(huì)發(fā)生什么故事？Clients 會(huì)一直可以讀、寫 Redis 3，這個(gè)前 master。當(dāng)分區(qū)合并時(shí)，Redis 3會(huì)被變成 Redis 1 的一個(gè) slave，在分區(qū)出現(xiàn)期間所寫入的數(shù)據(jù)都會(huì)丟失。依賴于你的配置你也許可以或不能接受這個(gè)場景： 如果將 Redis 作為 cache，Client B 在出現(xiàn)分區(qū)之后還能寫數(shù)據(jù)到前 master 就很方便，即便這個(gè)數(shù)據(jù)會(huì)丟失。

27、如果將 Redis 作為存儲(chǔ)，這樣就不好了，你需要配置系統(tǒng)來部分的預(yù)防這個(gè)問題。因?yàn)?Redis 是異步復(fù)制的，在上面這個(gè)場景中沒有完整的預(yù)防數(shù)據(jù)丟失的方法，但是你可以使用 Redis 的配置項(xiàng)來處理Redis 3和 Redis 1 之間的差異：min-slaves-to-write 1min-slaves-max-lag 10使用上面的配置（請(qǐng)參考 Redis 發(fā)現(xiàn)版本中的 redis.conf 例子自描述配置文件）一個(gè) Redis 實(shí)例，當(dāng) Redis 成為一個(gè) master，如果有一個(gè) slave 不能寫入，那么這個(gè) master 將會(huì)停止接收（clients）寫入請(qǐng)求。因?yàn)閺?fù)制是異步，

28、（clients）不能寫入意味著： slave 要么無法連接，或不會(huì)向我們發(fā)送超過 max-lag 秒之后的異步通告。上面的例子中，使用這個(gè)配置到 Redis 3，它會(huì)在 10秒后變成不可用。當(dāng)分區(qū)融合之后，Sentinel 3 會(huì)聚集到新的配置，Client B 就可以獲得一個(gè)有效的配置可以繼續(xù)工作。Sentinel狀態(tài)的持久化（Sentinel persistent state）Sentineld 的狀態(tài)被持久化到 sentinel 的配置文件。例如：對(duì)于一個(gè) master 每次收到一個(gè)新的配置，或創(chuàng)建（leader Sentinels），配置都會(huì)將其和配置的代一同持久化配置文件中。這意味

29、著停止和啟動(dòng)或重啟 Sentinel 是很安全的。故障恢復(fù)之外對(duì)Sentinel的重新配置（Sentinel reconfiguration of instances outside the failover procedure）即使沒有故障恢復(fù)，Sentinels 也會(huì)嘗試對(duì)監(jiān)控的 Redis 實(shí)例設(shè)置當(dāng)前的配置。特別是： Slaves （根據(jù)當(dāng)前的配置）中聲稱是master的，會(huì)被配置成為當(dāng)前 master 的一個(gè)slaves。 Slaves 連接到錯(cuò)誤的 master，會(huì)被配置連接正確的master。因?yàn)?Sentinels 會(huì)配置 slaves，這些錯(cuò)誤的配置必須被觀察一段時(shí)間，這比用

30、于廣播新配置的時(shí)間周期要大。這是為了避免干擾 Sentinels 的配置穩(wěn)定期間（如因網(wǎng)絡(luò)分區(qū)導(dǎo)致的分區(qū)融合）對(duì) slaves 的配置。還有，注意，總是嘗試聚集到當(dāng)前的配置的語義，使故障恢復(fù)過程更可以對(duì)抗分區(qū)： Masters 故障恢復(fù)后如果變的可用，會(huì)被重配置為slaves。 Slaves 如果被分區(qū)隔離，會(huì)在重新聚合之后被重新配置。Sentinel API默認(rèn)情況下 Sentinel 運(yùn)行在 26379 的TCP端口下（6379是一個(gè) Redis 實(shí)例的普通端口）。Sentinels 使用 Redis 的協(xié)議來接收命令，因此你可以使用 redis-cli 或其他 Redis 客戶端與 Se

31、ntinel 會(huì)話。有兩種和 Sentinel 會(huì)話的方式：可以直接從其查詢監(jiān)控的 Redis 進(jìn)程的狀態(tài)，看有那些其他的 Sentinels，等等。另外一個(gè)方式是使用 Pub/Sub 接收 Sentinels 推送的通知，每當(dāng)有事情發(fā)生，如故障恢復(fù)，或一個(gè)實(shí)例出現(xiàn)錯(cuò)誤，等等。Sentinel的命令（Sentinel commands）下面是可以接收的命令的列表： PING 這個(gè)命令簡單的返回 PONG。 SENTINEL masters 顯示有那些監(jiān)控的 masters，以及他們的狀態(tài)。 SENTINEL master 顯示指定的 master 的狀態(tài)和信息。 SENTINEL slaves

32、 顯示一個(gè) master 的 slaves 的列表，和他們的狀態(tài)。 SENTINEL get-master-addr-by-name 返回 master 的 ip 和 port。 如果一個(gè)故障恢復(fù)正在進(jìn)行或已經(jīng)成功的結(jié)束，會(huì)返回升級(jí)為master的那個(gè)slave的地址。 SENTINEL reset 這個(gè)命令會(huì)重新設(shè)置匹配 pattern 的 master。pattern 參數(shù)是 glob-style 的 pattern。reset 命令會(huì)清除master 之前的狀態(tài)（包括正在做的故障恢復(fù)），并去掉所有的被 master 發(fā)現(xiàn)和關(guān)聯(lián)的 slave 和 sentinel。 SENTINEL fa

33、ilover 強(qiáng)制指定的 master 進(jìn)行一次故障恢復(fù)，就像當(dāng)前的 master 已經(jīng)聯(lián)絡(luò)不上一樣，不需要請(qǐng)求其他sentinel的許可（是通過發(fā)布一個(gè)新版本的配置，從而強(qiáng)制其他 Sentinels 跟隨配置的方式實(shí)現(xiàn)的）。在運(yùn)行期重新配置 Sentinel （Reconfiguring Sentinel at Runtime）從 Redis version 2.8.4 開始，Sentinel 提供了一個(gè) API 用于加入、刪除或改變 一個(gè)master 的配置。注意，如果你有多個(gè) sentinels， 你應(yīng)該應(yīng)用配置變更到所有 Sentinel 實(shí)例，以使 Sentinel 正確的工作。這意

34、味著變更一個(gè) Sentinel 并不能使這個(gè)變更自動(dòng)的傳遞到網(wǎng)絡(luò)上的其他的 Sentinels 中。下面是可以變更一個(gè) Sentinel 配置的 SENTINEL 子命令的列表： SENTINEL MONITOR 這個(gè)命令告訴Sentinel 開始監(jiān)控一個(gè) master，使用給出的IP、端口和法定人數(shù)。這個(gè)和 sentinel.conf 中的配置信息一致，只是你不能使用 hostname 作為IP，可以使用 IPv4或 IPv6。 SENTINEL REMOVE 用于刪除指定的 master：這個(gè) master 將不再被這個(gè) Sentinel 監(jiān)控，并完全的從這個(gè) Sentinel 的內(nèi)部狀態(tài)

35、中刪除，因此不會(huì)被 SENTINEL masters返回，等等。 SENTINEL SET 這個(gè) SET 命令與 Redis 的 CONFIG SET 命令相似，用于變更指定 master 的配置參數(shù)。在一個(gè)命令中可以指定多個(gè)配置項(xiàng)（或一個(gè)都沒有）。所有的配置參數(shù)可以通過 sentinel.conf 或 SET 命令來設(shè)置。下面是一個(gè) SENTINEL SET 命令的例子，用于變更 master 的 down-after-milliseconds 配置參數(shù)：SENTINEL SET objects-cache-master down-after-milliseconds 1000想已經(jīng)說的，S

36、ENTINEL SET 可以用于設(shè)置配置文件中所有的可配置參數(shù)。更進(jìn)一步，它還可以調(diào)整 master 的 法定人數(shù)（quorum）的配置信息，不需要經(jīng)過添加、刪除 master 的過程，僅是簡單的：SENTINEL SET objects-cache-master quorum 5注意，沒有提供對(duì)應(yīng)的 GET 命令，因?yàn)?SENTINEL MASTER 命令可以提供全部的配置參數(shù)信息。Pub/Sub消息（Pub/Sub Messages）一個(gè) client 可以使用 Sentinel 作為 Redis 兼容的 Pub/Sub 服務(wù)器（不能使用 PUBLISH命令）用于SUBSCRIBE或PSU

37、BSCRIBE到那些通訊通道，獲取指定的事件。這個(gè)通訊通道的名字和事件的名稱相同。比如，名字是 +sdown 的通訊通道的名字 能接收所有的 進(jìn)入SDOWN的實(shí)例發(fā)出的相關(guān)的通知。使用 PSUBSCRIBE * 獲取全部的消息。下面是可以接收的所有的消息通道的列表和信息的格式。 第一個(gè)詞是 信息通道/事件的名稱，其余部分是數(shù)據(jù)的格式。注：那些instance detailsis 指定表示這部分信息是和目標(biāo)的實(shí)例相關(guān)的： 指示 master 的部分（從到最后）是可以省略的，是僅用于指定本身不是一個(gè) master 的實(shí)例。 +reset-master - master 被 reset。 +slav

38、e - 一個(gè)新的 slave 被檢測(cè)到，并被加入。 +failover-state-reconf-slaves - 錯(cuò)誤恢復(fù)（failover）狀態(tài) 變更到 重新配置 slaves （reconf-slaves）狀態(tài)。 +failover-detected - 一個(gè)錯(cuò)誤恢復(fù)被其他 Sentinel 啟動(dòng)，或任何其它 外部的事實(shí)被檢測(cè)到（一個(gè)加入的 slave 被變更成 master）。 +slave-reconf-sent - 領(lǐng)導(dǎo)的 sentinel 發(fā)送 SLAVEOF命令到這個(gè) redis 實(shí)例以便重新配置這個(gè)新的slave。 +slave-reconf-inprog - 這個(gè) slav

39、e 正在被重新配置成為新 master （ip:port對(duì)表示）的 slave ，但是這個(gè)同步配置過程還沒結(jié)束。 +slave-reconf-done - 這個(gè) slave 現(xiàn)在和新 master 同步了。 -dup-sentinel - 一個(gè)或多個(gè)指定 master 的sentinels 因?yàn)橹貜?fù) 被刪除了（這一般在一個(gè) Sentinel 進(jìn)程重啟的時(shí)候會(huì)出現(xiàn)）。 +sentinel - 指定的 master 的一個(gè)新的 sentinel 被檢測(cè)到并被添加。 +sdown - 指定的實(shí)例現(xiàn)在成為 SDOWN 的狀態(tài)。 -sdown - 指定的實(shí)例不再是 SDOWN 的狀態(tài)。 +odown - 指定的實(shí)例現(xiàn)在成為 ODOWN 的狀態(tài)。 -odown - 指定的實(shí)例不再是 ODOWN 的狀態(tài)。 +new-epoch - 當(dāng)前的代被更新了。 +try-failover - 一個(gè)新的故障恢復(fù)正在處理，等待主體的選舉。 +elected-leader - 指定的代贏得了主體的選舉，可以執(zhí)行故障恢復(fù)。 +failover-state-select-slave - 新的