溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
上一篇介紹了Redis的主從服務器之間是如何同步數據的。試想下，在一主一從或一主多從的結構下，如果主服務器掛了，整個集群就不可用了，單點問題并沒有解決。Redis使用Sentinel解決該問題，保障集群的高可用。
保障集群高可用，要具備如下能力：
能監測服務器的狀態，當主服務器不可用時，能及時發現
當主服務器不可用時，選擇一臺最合適的從服務器替代原有主服務器
存儲相同數據的主服務器同一時刻只有一臺
要實現上述功能，最直觀的做法就是，使用一臺監控服務器來監視Redis
服務器的狀態。
監控服務器和主從服務器間維護一個心跳連接，當超出一定時間沒有收到主服務器心跳時，主服務器就會被標記為下線，然后通知從服務器上線成為主服務器。
當原來的主服務器上線后，監控服務器會將其轉換為從服務器。
按照上述流程似乎解決了集群高可用的問題，但似乎有哪里不對：如果監控服務器出了問題怎么辦？我們可以在加上一個從監控服務器，當主服務器不可用的時候頂上。
但問題是誰來監控’監控服務器’呢？子子孫孫無窮盡也。。
先把疑問放在一旁，先來看下Redis 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會通過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最小的那個
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
