分散式Redis深度歷險-Sentinel

做個好人君發表於2018-09-03

本文為分散式Redis深度歷險系列的第二篇,主要內容為Redis的Sentinel功能。 更多文章見個人部落格:github.com/farmerjohng…

上一篇介紹了Redis的主從伺服器之間是如何同步資料的。試想下,在一主一從或一主多從的結構下,如果主伺服器掛了,整個叢集就不可用了,單點問題並沒有解決。Redis使用Sentinel解決該問題,保障叢集的高可用。

如何保障叢集高可用

保障叢集高可用,要具備如下能力:

  • 能監測伺服器的狀態,當主伺服器不可用時,能及時發現
  • 當主伺服器不可用時,選擇一臺最合適的從伺服器替代原有主伺服器
  • 儲存相同資料的主伺服器同一時刻只有一臺

要實現上述功能,最直觀的做法就是,使用一臺監控伺服器來監視Redis 伺服器的狀態。

image

監控伺服器和主從伺服器間維護一個心跳連線,當超出一定時間沒有收到主伺服器心跳時,主伺服器就會被標記為下線,然後通知從伺服器上線成為主伺服器。

image

當原來的主伺服器上線後,監控伺服器會將其轉換為從伺服器。

image

按照上述流程似乎解決了叢集高可用的問題,但似乎有哪裡不對:如果監控伺服器出了問題怎麼辦?我們可以在加上一個從監控伺服器,當主伺服器不可用的時候頂上。

image

但問題是誰來監控'監控伺服器'呢?子子孫孫無窮盡也。。

先把疑問放在一旁,先來看下Redis Sentinel叢集的實現

Sentinel

和上一小節的想法一樣,Redis通過增加額外的Sentinel伺服器來監控資料伺服器,Sentinel會與所有的主伺服器和從伺服器儲存連線,用以監聽伺服器狀態以及向伺服器下達命令。

image

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即向該頻道釋出訊息,又從該頻道訂閱訊息。

image

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最小的那個

相關文章