Redis-sentinel是Redis例項的監控管理、通知和例項失效備援服務，是Redis叢集的管理工具。在一般的分散式中心節點資料庫中，Redis-sentinel的作用是中心節點的工作，監控各個其他節點的工作情況並且進行故障恢復，來提高叢集的高可用性。

Redis-sentinel是Redis的作者antirez在今年6月份完成的，因為Redis例項在各個大公司的應用，每個公司都需要一個Redis叢集的管理工具，被迫都自己寫管理工具來管理Redis叢集，antirez考慮到社群的急迫需要(詳情)，花了幾個星期寫出了Redis-sentinel。

Redis-sentinel的三大功能: * 監測 * 通知 * 自動故障恢復 首先Redis-sentinel要建立一個監控的master列表，然後針對master列表的每個master獲取監控其的sentinels和slaves供以後故障恢復使用。

自動發現sentinel和slave

一個sentinel例項的監控master在配置檔案中指定，如sentinel A在配置檔案中指定管理的master ip:port列表，並且指定連線失敗超時的時間和是否可以故障恢復等引數。這樣，sentinel A就建立了監控的master列表。

sentinel A作為客戶端建立對其監控master 1的pub/sub連線和命令傳輸連線，pub/sub連線的目的是通過訊息傳遞來獲取監控master 1的所有sentinels，具體方式是訂閱”sentinel:hello”頻道，並這個頻道publish 自己的host資訊，這樣，所有監控master 1的sentinels都通過訂閱master 1的“sentinel

故障恢復準備

Redis-sentinel定義了故障的master兩種狀態，O_DOWN(objectively)和S_DOWN(subobjectively)。當sentinel A連線master 1失敗後，sentinel A認定master 1為subobjectively狀態，然後sentinel A檢視監控master 1的sentinels的認定情況。因為sentinel之間會建立連線並且不斷的發起info命令詢問和迴應，因此在sentinel A認定master 1 S_DOWN後，sentinel A通過SENTINEL IS-MASTER-DOWN-BY-ADDR命令來不斷獲得其他sentinel的認定情況，如果有超過quorum(配置中指定)個sentinel認定master 1已經DOWN，那麼就確定master 1為O_DOWN。然後sentinel

A必須有master 1的can failover許可權，這也是配置檔案指定的。接著，sentinel A需要得知master 1的leader sentinel，由leader來進行master 1的錯誤恢復。

master 1的leader sentinel由選舉產生，每個監控master 1的，並且具有錯誤恢復許可權的sentinel都需要進行一次叫做subjective leader判斷，也就是sentinel自己認定的leader，然後sentinel之間通過SENTINEL IS-MASTER-DOWN-BY-ADDR命令交流leader的認定情況，然後最終得到一個共識。

然後由這個master 1的leader sentinel來啟動錯誤恢復例程。

故障處理

sentinel A作為master 1的leader，會選取一個master 1的slave作為新的master。slave的選取是根據一個判斷DNS情況的優先順序來得到，優先順序相同通過runid的排序得到，但目前優先順序設定還沒實現，所以直接獲取runid排序得到slave 1。

然後傳送命令slaveof no one來取消slave 1的slave狀態來轉換為master。當其他sentinel觀察到該slave成為master後,就知道錯誤處理例程啟動了。sentinel A然後傳送給其他slave slaveof

new-slave-ip-port 命令，當所有slave都配置完後，sentinel A從監測的masters列表中刪除故障master，然後通知其他sentinels。

總結

Redis-sentinel作為一個叢集管理工具，基本滿足了要求。但是Redis叢集的需求卻仍然存在。Redis叢集作為分割槽結果，分割槽的配置仍然需要客戶端或者代理協議實現，Redis叢集作為一個整體還需要更長的路。Redis-cluster的草案早於出爐，但是實現卻已經停留了很久。antriez承諾在Redis 3.0推出Redis-cluster功能。