本文為分散式Redis深度歷險系列的第二篇，主要內容為Redis的Sentinel功能。 更多文章見個人部落格：github.com/farmerjohng…
上一篇介紹了Redis的主從伺服器之間是如何同步資料的。試想下，在一主一從或一主多從的結構下，如果主伺服器掛了，整個叢集就不可用了，單點問題並沒有解決。Redis使用Sentinel解決該問題，保障叢集的高可用。
如何保障叢集高可用
保障叢集高可用，要具備如下能力：
- 能監測伺服器的狀態，當主伺服器不可用時，能及時發現
- 當主伺服器不可用時，選擇一臺最合適的從伺服器替代原有主伺服器
- 儲存相同資料的主伺服器同一時刻只有一臺
要實現上述功能，最直觀的做法就是，使用一臺監控伺服器來監視Redis 伺服器的狀態。
監控伺服器和主從伺服器間維護一個心跳連線，當超出一定時間沒有收到主伺服器心跳時，主伺服器就會被標記為下線，然後通知從伺服器上線成為主伺服器。
當原來的主伺服器上線後，監控伺服器會將其轉換為從伺服器。
按照上述流程似乎解決了叢集高可用的問題，但似乎有哪裡不對：如果監控伺服器出了問題怎麼辦？我們可以在加上一個從監控伺服器，當主伺服器不可用的時候頂上。
但問題是誰來監控'監控伺服器'呢？子子孫孫無窮盡也。。
先把疑問放在一旁，先來看下Redis Sentinel叢集的實現
Sentinel
和上一小節的想法一樣，Redis通過增加額外的Sentinel伺服器來監控資料伺服器，Sentinel會與所有的主伺服器和從伺服器儲存連線，用以監聽伺服器狀態以及向伺服器下達命令。
Sentinel本身是一個特殊狀態的Redis伺服器，啟動命令：
redis-server /xxx/sentinel.conf --sentinel,sentinel模式下的啟動流程與普通redis server是不一樣的，比如說不會去載入RDB檔案以及AOF檔案，本身也不會儲存業務資料。
與主伺服器建立連線
Sentinel啟動後，會與配置檔案中提供的所有主伺服器建立兩個連線，一個是命令連線，一個是訂閱連線。
命令連線用於向伺服器傳送命令。
訂閱連線則是用於訂閱伺服器的_sentinel_:hello頻道，用於獲取其他Sentinel資訊，下文會詳細說。
獲取主伺服器資訊
Sentinel會以一定頻率向主伺服器傳送Info命令獲取資訊，包括主伺服器自身的資訊比如說伺服器id等，以及對應的從伺服器資訊，包括ip和port。Sentinel會根據info命令返回的資訊更新自己儲存的伺服器資訊，並會與從伺服器建立連線。
獲取從伺服器資訊
與和主伺服器的互動相似，Sentinel也會以一定頻率通過Info命令獲取從伺服器資訊，包括：從伺服器ID，從伺服器與主伺服器的連線狀態，從伺服器的優先順序，從伺服器的複製偏移等等。
向伺服器訂閱和釋出訊息
在如何保障叢集高可用小節留下了一個疑問：用如何保證監視伺服器的高可用？ 在這裡我們可以先給出簡單回答：用一個監視伺服器叢集（也就是Sentinel叢集）。如何實現，如何保證監視伺服器的一致性暫且先不說，我們只要記住需要用若干臺Sentinel來保障高可用，那一個Sentinel是如何感知其他的Sentinel的呢？
前面說過，Sentinel在與伺服器建立連線時，會建立兩個連線，其中一個是訂閱連線。Sentinel會定時的通過訂閱連線向_sentinel_:hello頻道頻道傳送訊息（對Redis釋出訂閱功能不太瞭解的同學可以去去了解下），其中包括：
- Sentinel本身的資訊，如ip地址、埠號、配置紀元（見下文）等
- Sentinel監視的主伺服器的資訊，包括ip、埠、配置紀元（見下文）等
同時，Sentinel也會訂閱_sentinel_:hello頻道的訊息，也就是說Sentinel即向該頻道釋出訊息，又從該頻道訂閱訊息。
Sentinel有一個字典物件sentinels，儲存著監視同一主伺服器的其他所有Sentinel伺服器，當一個Sentinel接收到來自_sentinel_:hello頻道的訊息時，會先比較傳送該訊息的是不是自己，如果是則忽略，否則將更新sentinels中的內容，並對新的Sentinel建立連線。
主觀下線
Sentinel預設會以每秒一次的頻率向所有建立連線的伺服器（主伺服器，從伺服器，Sentinel伺服器）傳送PING命令，如果在down-after-milliseconds內都沒有收到有效回覆,Sentinel會將該伺服器標記為主觀下線，代表該Sentinel認為這臺伺服器已經下線了。需要注意的是不同Sentinel的down-after-milliseconds是可以不同的。
客觀下線
為了確保伺服器真的已經下線，當Sentinel將某個伺服器標記為主觀下線後，它會向其他的Sentinel例項傳送Sentinel is-master-down-by-addr命令，接收到該命令的Sentinel例項會回覆主伺服器的狀態，代表該Sentinel對該主伺服器的連線情況。
Sentinel會統計發出的所有Sentinel is-master-down-by-addr命令的回覆，並統計同意將主伺服器下線的數量，如果該數量超出了某個閾值，就會將該主伺服器標記為客觀下線。
選舉領頭Sentinel
當Sentinel將一個主伺服器標記為客觀下線後，監視該伺服器的各個Sentinel會通過Raft演算法進行協商，選舉出一個領頭的Sentinel。
建議你先看Raft演算法的基礎知識，再來看下文。
規則：
- 所有的Sentinel都有可能成為領頭Sentinel的資格
- 每次選舉後，無論有沒有選出領頭Sentinel，配置紀元都會+1
- 在某個紀元裡，每個Sentinel都有為投票的機會
- 我們稱要求其他人選舉自己的Sentinel稱為源Sentinel，將被要求投票的Sentinel稱為目標Sentinel
- 每個發現主伺服器被標記為客觀下線且還沒有被其他Sentinel要求投票的Sentinel都會要求其他Sentinel將自己設定為頭
- 目標Sentinel在一個配置紀元裡，一旦為某個Sentinel（也可能是它自己）投票後，對於之後收到的要求投票的命令，將拒絕
- 目標Sentinel對於要求投票的命令將回復自己選舉的Sentinel的id以及當前配置紀元
- 源Sentinel在接收到要求投票的回覆後：如果回覆的配置紀元與自己的相同，則再檢測目標Sentinel選舉的頭Sentinel是不是自己
- 如果某個Sentinel被半數以上的Sentinel設定成了領頭Sentinel，那它將稱為領頭Sentinel
- 一個配置紀元只會選出一個頭（因為一個頭需要半數以上的支援）
- 如果在給定時間內，還沒有選出頭，則過段時間再次選舉（配置紀元會+1）
還記得我們在文章開頭提出的如何保證Redis伺服器高可用的問題嗎？
答案就是使用若干臺Sentinel伺服器，通過Raft一致性演算法來保障叢集的高可用，只要Sentinel伺服器有一半以上的節點都正常，那叢集就是可用的。
故障轉移
領頭Sentinel將會進行以下3個步驟進行故障轉移：
1.在已下線主伺服器的所有從伺服器中，挑選出一個作為新的主伺服器
2.將其他從伺服器的主伺服器設定成新的
3.將已下線的主伺服器的role改成從伺服器，並將其主伺服器設定成新的，當該伺服器重新上線後，就會一個從伺服器的角色繼續工作
第一步中挑選新的主伺服器的規則如下：
1.過濾掉所有已下線的從伺服器
2.過濾掉最近5秒沒有回覆過Sentinel命令的從伺服器
3.過濾掉與原主伺服器斷開時間超過down-after-milliseconds*10的從伺服器
4.根據從伺服器的優先順序進行排序，選擇優先順序最高的那個
5.如果有多個從伺服器優先順序相同，則選取複製偏移量最大的那個
6.如果上一步的伺服器還有多個，則選取id最小的那個