分佈式Redis深度歷險-Sentinel

上一篇介紹了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最小的那個

 

原文：Java架構筆記

免費Java高級資料須要本身領取，涵蓋了Java、Redis、MongoDB、MySQL、Zookeeper、Spring Cloud、Dubbo高併發分佈式等教程，一共30G。            
傳送門：             https://mp.weixin.qq.com/s/JzddfH-7yNudmkjT0IRL8Q