Redis Sentinel 是 Redis 的官方高可用解決方案，是設計用來幫助管理 Redis 實例的系統(tǒng)。用于完成下面 4 個任務：

• 監(jiān)控(Monitoring)。Sentinel 不斷檢查你的主從實例是否運轉正常。
• 通知(Notification)。Sentinel 可以通過 API 來通知系統(tǒng)管理員，或者其他計算機程序，被監(jiān)控的 Redis 實例出了問題。
• 自動故障轉移(Automatic failover)。如果一臺主服務器運行不正常，Sentinel 會開始一個故障轉移過程，將從服務器提升為主服務器，配置其他的從服務器使用新的主服務器，使用 Redis 服務器的應用程序在連接時會收到新的服務器地址通知。
• 配置提供者(Configuration provider)。Sentinel 充當客戶端服務發(fā)現(xiàn)的權威來源：客戶端連接到 Sentinel 來詢問某個服務的當前 Redis 主服務器的地址。當故障轉移發(fā)生時，Sentinel 會報告新地址。

分布式特性(Distributed nature)

Redis Sentinel 是一個分布式系統(tǒng)，這意味著，你通常想要在你的基礎設施中運行多個 Sentinel 進程，這些進程使用 gossip 協(xié)議來判斷一臺主服務器是否下線(down)，使用 agreement 協(xié)議來獲得授權以執(zhí)行故障轉移，并更新相關配置。

分布式系統(tǒng)具有特定的安全(safety)和活性(liveness)的問題，為了更好地使用 Redis Sentinel，你應該去理解 Sentinel 是如何作為一個分布式系統(tǒng)運轉的，至少在較高的層面上。這會讓 Sentinel 變得更復雜，但是比單進程系統(tǒng)更好，例如：

• Sentinel 集群能對主服務器故障轉移，即使部分 Sentinel 失敗。
• 單個 Sentinel 工作不正常，或者連接不正常，在沒有別的 Sentinel 授權的情況下不能故障轉移主服務器。
• 客戶端可以隨機連接到任何一個 Sentinel 來獲取主服務器的配置信息。

獲取 Sentinel(Obtaining Sentinel)

當前版本的 Sentinel 被稱為 Sentinel 2。使用了更強大和簡單的算法來重寫最初的 Sentinel 實現(xiàn) (本文后面會解釋)。

穩(wěn)定版本的 Redis Sentinel 被打包在 Redis 2.8 中，這是最新的 Redis 版本。

新的開發(fā)在不穩(wěn)定的分支中進行，新的特性一旦穩(wěn)定了就會合并回 2.8 分支。

重要：即使你使用的是 Redis 2.6，你也應該使用 Redis 2.8 自帶的 Sentinel。Redis 2.6 自帶的 Sentinel，也就是 Sentinel 1，已經不贊成使用，并且有很多的 bug。總之，你應該盡快把你的 Redis 和 Sentinel 實例都遷移到 Redis 2.8，以獲得更好的全面體驗。

運行 Sentinel(Running Sentinel)

如果你使用 redis-sentinel 可執(zhí)行文件 (或者如果你有一個叫這個名字的到 redis-server 的符號鏈接)，你可以使用下面的命令行來運行 Sentinel：

redis-sentinel  /path/to/sentinel.conf  

另外，你可以直接使用 redis-server 可執(zhí)行文件并作為 Sentinel 模式啟動：

redis-server  /path/to/sentinel.conf  --sentinel  

兩種方式是一樣的。

但是，運行 Sentinel 強制使用配置文件，這個文件被系統(tǒng)用來保存當前狀態(tài)，在重啟時能重新加載。如果沒有指定配置文件，或者配置文件的路徑不可寫，Sentinel 將拒絕啟動。

Sentinel 運行時默認監(jiān)聽 TCP 端口 26379，所以為了讓 Sentinel 正常運行，你的服務器必須開放 26379 端口，以接受從其他 Sentinel 實例 IP 地址的連接。否則，Sentinel 間就沒法通信，沒法協(xié)調，也不會執(zhí)行故障轉移。

配置 Sentinel(Configuring Sentinel)

Redis 的源碼發(fā)行版中包含一個叫做 sentinel.conf 的自說明示例配置文件，可以用來配置 Sentinel，一個典型的最小配置文件看起來就像下面這樣：

sentinel  monitor  mymaster  127.0.0.1  6379  2  
sentinel  down-after-milliseconds  mymaster  60000  
sentinel  failover-timeout  mymaster  180000  
sentinel  parallel-syncs  mymaster  1  

sentinel  monitor  resque  192.168.1.3  6380  4  
sentinel  down-after-milliseconds  resque  10000  
sentinel  failover-timeout  resque  180000  
sentinel  parallel-syncs  resque  5  

你只需要指定你要監(jiān)控的主服務器，并給每一個主服務器(可以擁有任意多個從服務器)一個不同的名字。沒有必要指定從服務器，因為它們會被自動發(fā)現(xiàn)。Sentinel 會根據(jù)從服務器的額外信息來自動更新配置(為了在重啟時還能保留配置)。每次故障轉移時將一臺從服務器提升為主服務器時都會重寫配置文件。

上面的示例配置監(jiān)控了兩個 Redis 實例集合，每個由一個主服務器和未知數(shù)量的從服務器組成。其中一個實例集合叫做 mymaster，另一個叫做 resque。

為了說得再清楚一點，我們一行一行地來看看這些配置選項是什么意思：

第一行告訴 Redis 監(jiān)控一個叫做 mymaster 的主服務器，地址為 127.0.0.1，端口為 6379，判斷這臺主服務器失效需要 2 個 Sentinel 同意(如果同意數(shù)沒有達到，自動故障轉移則不會開始)。

但是要注意，無論你指定多少個同意來檢測實例是否正常工作，Sentinel 需要系統(tǒng)中已知的大多數(shù) Sentinel 的投票才能開始故障轉移，并且在故障轉移之后獲取一個新的配置紀元(configuration Epoch) 賦予新的配置。

在例子中，仲裁人數(shù) (quorum) 被設置為 2，所以使用 2 個 Sentinel 同意某臺主服務器不可到達或者在一個錯誤的情況中，來觸發(fā)故障轉移(但是，你后面還會看到，觸發(fā)一個故障轉移還不足以開始一次成功的故障轉移，還需要授權)。

其他的選項基本上都是這樣的形式：

sentinel  <option_name>  <master_name>  <option_value>  

它們的作用如下：

down-after-milliseconds 表示要使 Sentinel 開始認為實例已下線(down)，實例不可到達(沒有響應我們的 PING，或者響應一個錯誤) 的毫秒數(shù)。這個時間過后，Sentinel 將標記實例為主觀下線(subjectively down，也稱 SDOWN)，這還不足以開啟自動故障轉移。但是，如果足夠的實例認為具備主觀下線條件，實例就會被標記為客觀下線(objectively down)。需要同意的 Sentinel 數(shù)量依賴于為這臺主服務器的配置。

parallel-syncs 設置在一次故障轉移之后，被配置為同時使用新主服務器的從服務器數(shù)量。這個數(shù)字越小，完成故障轉移過程需要的時間就越多，如果從服務器配置為服務舊數(shù)據(jù)，你可能不太希望所有的從服務器同時從新的主服務器重同步，盡管復制過程通常不會阻塞從服務器，但是在重同步過程中仍然會有一段停下來的時間來加載來自于主服務器的大量數(shù)據(jù)。設置這個選項的值為 1 可以確保每次只有一個從服務器不可用。

其他的選項將在本文的剩余篇幅里介紹，Redis 發(fā)行版本中自帶的示例 sentinel.conf 文件中也有詳細的文檔。

所有的配置參數(shù)可以在運行時用 SENTINEL SET 命令修改。請看下文中運行時重新配置 Sentinel 這一部分獲取更多的信息。

仲裁人數(shù)(Quorum)

本文前面的部分展示了每一個被 Sentinel 監(jiān)控的主服務器都關聯(lián)了一個仲裁人數(shù)的配置。它指定了同意主服務器不可達或者錯誤條件需要的 Sentinel 進程數(shù)，以觸發(fā)一次故障轉移。

但是，故障轉移被觸發(fā)后，為了讓故障轉移真正執(zhí)行，必須至少大多數(shù)的 Sentinel 授權某個 Sentinel 才能錯誤轉移。

讓我們解釋的再清楚一些：

• 仲裁人數(shù)：檢測錯誤條件以標記主服務器為 ODOWN 所需要的 Sentinel 進程數(shù)。
• 故障轉移由 ODOWN 狀態(tài)觸發(fā)。
• 一旦故障轉移被觸發(fā)，故障轉移的 Sentinel 需要向大多數(shù) Sentinel 請求授權(或者大于大多數(shù)，如果仲裁人數(shù)設置為大于大多數(shù)的話)。

差別看起來很微妙，但是實際上理解和使用起來都相當簡單。例如，如果你有 5 個 Sentinel 實例，然后設置仲裁人數(shù)為 2，只要有 2 個 Sentinel 認為主服務器不可達就會觸發(fā)一次故障轉移，這兩個 Sentinel 僅當?shù)玫街辽?3 個 Sentinel 的授權時才能故障轉移。

如果設置仲裁人數(shù)為 5，所有的 Sentinel 都必須同意主服務器的錯誤條件，故障轉移需要所有 Sentinel 的授權。

配置紀元 (Configuration epochs)

Sentinel 需要大多數(shù)的授權來開啟故障轉移是有幾個重要原因的：

當一個 Sentinel 得到授權了，就會為故障轉移的主服務器獲得一個唯一的配置紀元。這是在故障轉移完成后用于標記新的配置的一個版本數(shù)字。因為大多數(shù)同意將一個指定的版本賦予一個指定的 Sentinel，所以其它的 Sentinel 不能使用它。這意味著，每一次故障轉移的配置都使用一個唯一的版本來標記。我們會看到為什么這個是如此的重要。

另外，Sentinel 有一個規(guī)則：如果一個 Sentinel 為了指定的主服務器故障轉移而投票給另一個 Sentinel，將會等待一段時間后試圖再次故障轉移這臺主服務器。這個延時(delay)是 failover-timeout，你可以在 sentinel.conf 中配置。這意味著，Sentinel 不會同時故障轉移同一臺主服務器，第一個請求被授權的將會嘗試，如果失敗了，過一會后另一個將會嘗試，等等。

Redis Sentinel 保證活性(liveness)屬性，如果大多數(shù) Sentinel 能夠對話，如果主服務器下線，最后只會有一個被授權來故障轉移。

Redis Sentinel 也保證安全(safety)屬性，每個 Sentinel 將會使用不同的配置紀元來故障轉移同一臺主服務器。

配置傳播(Configuration propagation)

一旦一個 Sentinel 能夠成功故障轉移一臺主服務器，會開始廣播新的配置，從而使其他 Sentinel 更新關于這臺主服務器的信息。

為了認定故障轉移是成功的，需要 Sentinel 能發(fā)送 SLAVEOF NO ONE 給選定的從服務器，并將其切換為主服務器，稍后可以在主服務器的 INFO 輸出中觀察到。

這時，即使從服務器的重新配置還在進行中，故障轉移被認為是成功的，所有的 Sentinel 被要求開始報告新的配置。

新配置傳播的方式，就是為什么我們需要每次 Sentinel 故障轉移時被授權一個不同的版本號(配置紀元)的原因。

每一個 Sentinel 使用 Redis 的發(fā)布訂閱(Pub/Sub)消息不斷地廣播主服務器的配置版本，在主服務器上以及所有從服務器上。與此同時，所有的 Sentinel 等待其它 Sentinel 通知的配置消息。

配置信息在__sentinel__:hello 頻道中廣播。

因為每一個配置有一個不同的版本號，所以更大的版本號總是勝過更小的版本號。

例如，一開始所有的 Sentinel 認為主服務器 mymaster 的配置為 192.168.1.50:6379。這個配置擁有版本 1。一段時間以后，一個 Sentinel 被授權以版本 2 來故障轉移。如果故障轉移成功，會廣播一個新的配置，比如說 192.168.1.50:9000，作為版本 2。所有其他實例會看到這個配置，并相應地更新它們的配置，因為新的配置擁有一個更大的版本號。

這意味著，Sentinel 保證第二個活性屬性：一個可以相互通信的 Sentinel 集合會統(tǒng)一到一個擁有更高版本號的相同配置上。

基本上，如果網絡是分割的，每個分區(qū)會統(tǒng)一到一個更高版本的本地配置。在沒有分割的特殊情況下，只有一個分區(qū)，每個 Sentinel 將會配置一致。

SDOWN 和 ODOWN 更多細節(jié)

正如本文已經簡要提到的，Redis Sentinel 有兩個不同的下線概念，一個被稱為主觀下線條件(SDOWN)，一個本地 Sentinel 實例的下線條件。另一個稱為客觀下線條件(ODOWN)，當足夠的 Sentinel(至少為主服務器 quorum 參數(shù)配置的數(shù)量) 具有 SDOWN 條件時就滿足 ODOWN，并且使用 SENTINEL is-master-down-by-addr 命令從其它 Sentinel 獲得反饋。

從 Sentinel 的角度來看，如果我們沒有在配置的 is-master-down-after-milliseconds 參數(shù)的指定時間內收到一個 PING 請求的合法響應，就達到了 SDOWN 的條件。

PING 的可接受響應可以是以下其中之一：

• 回復 + PONG。
• 回復 - LOADING 錯誤。
• 回復 - MASTERDOWN 錯誤。

其它回復 (或者沒有回復) 都被認為是不合法的。

注意，SDOWN 需要在配置的整個時間區(qū)間內沒有收到可以接受的回復，例如，如果間隔配置為 30000 毫秒(30 秒)，我們每隔 29 秒收到一個可以接受的 ping 回復，實例被認為是正常工作的。

從 SDOWN 切換到 ODOWN 沒有使用強一致性算法，而僅僅是 gossip 的形式：如果一個指定的 Sentinel 在指定的時間范圍內從足夠多的 Sentinel 那里獲得關于主服務器不工作的報告，SDOWN 就被提升為 ODOWN。如果這種報告不再收到，(ODOWN)標記就會被清除。

正如已經解釋過的，真正開始故障轉移需要更嚴格的授權，但是，如果沒有達到 ODOWN 狀態(tài)，是不會觸發(fā)故障轉移的。

ODOWN 條件只適用于主服務器。對于其他的實例，Sentinel 不需要任何同意，所以從服務器和其它 Sentinel 永遠都不會達到 ODOWN 狀態(tài)。

自動發(fā)現(xiàn)(Auto discovery)

Sentinel 之間保持著連接來互相檢查彼此的可用性，互相交換信息，你不需要在每個你運行的 Sentinel 實例中配置其他 Sentinel 的地址，因為 Sentinel 使用 Redis 主服務器的發(fā)布訂閱能力來發(fā)現(xiàn)監(jiān)控同一臺主服務器的其他 Sentinel。

這是通過向名為__sentinel__:hello 頻道發(fā)送問候消息 (Hello Messages) 實現(xiàn)的。

同樣，你不需要配置連接在主服務器上的從服務器列表，因為 Sentinel 會通過詢問 Redis 自動發(fā)現(xiàn)這個列表。

• 每個 Sentinel 每隔 2 秒向每個被監(jiān)控的主服務器和從服務器的發(fā)布訂閱頻道__sentinel__:hello 發(fā)送一條消息，報告自己的存在狀態(tài)：IP 地址，端口號和 runid。
• 每個 Sentinel 訂閱了每個主服務器和從服務器的發(fā)布訂閱頻道__sentinel__:hello，尋找未知的 Sentinel。當檢測到新的 Sentinel，就將其添加到這臺主服務器的 Sentinel 列表中。
• 問候消息也包括主服務器當前的完整配置。如果另一個 Sentinel 擁有一個比接收到的更老的主服務器配置，會立刻更新為新的配置。
• 在添加一個新的 Sentinel 到主服務器前，Sentinel 總是檢查是否已經有一個相同的 runid 或者相同地址(IP 地址和端口對)的 Sentinel。如果是的話，所有匹配的 Sentinel 將會被刪除，新的被添加。