摘要：可以通過以下兩個配置盡量減少數據丟失的可能從零單排學鉑金三，敬請期待參考資料設計與實現實戰如果你覺得我寫得還不錯，了解一下堅持原創的技術公眾號。

只有光頭才能變強

好的，今天我們要上【鉑金二】了，如果還沒有上鉑金的，趕緊先去蹭蹭經驗再回來(不然不帶你上分了)：

從零單排學Redis【青銅】

從零單排學Redis【白銀】

從零單排學Redis【黃金】

從零單排學Redis【鉑金一】

在上篇中拋出了一個問題：

拋個問題：如果從服務器掛了，沒關系，我們一般會有多個從服務器，其他的請求可以交由沒有掛的從服務器繼續處理。如果主服務器掛了，怎么辦？因為我們的寫請求由主服務器處理，只有一臺主服務器，那就無法處理寫請求了？

Redis提供了哨兵(Sentinal)機制供我們解決上面的情況。如果主服務器掛了，我們可以將從服務器升級為主服務器，等到舊的主服務器(掛掉的那個)重連上來，會將它(掛掉的主服務器)變成從服務器。

這個過程叫做主備切換(故障轉移)

在正常的情況下，主從加哨兵(Sentinal)機制是這樣子的：

主服務器掛了，主從復制操作就中止了，并且哨兵系統是可以察覺出主服務掛了。：

Redis提供哨兵機制可以將選舉一臺從服務器變成主服務器

然后舊的主服務器如果重連了，會變成從服務器：

這篇文章主要講講Redis的哨兵(Sentinal)機制的一些細節。希望看完對大家有所幫助~

High Availability: Redis Sentinel is the official high availability solution for Redis.

哨兵(Sentinal)機制主要用于實現Redis的高可用性，主要的功能如下：

Monitoring. Sentinel constantly checks if your master and slave instances are working as expected.

Sentinel不停地監控Redis主從服務器是否正常工作

Notification. Sentinel can notify the system administrator, another computer programs, via an API, that something is wrong with one of the monitored Redis instances.

如果某個Redis實例有故障，那么哨兵負責發送消息通知管理員

Automatic failover. If a master is not working as expected, Sentinel can start a failover process where a slave is promoted to master, the other additional slaves are reconfigured to use the new master, and the applications using the Redis server informed about the new address to use when connecting.

如果主服務器掛掉了，會自動將從服務器提升為主服務器(包括配置都會修改)。

Configuration provider. Sentinel acts as a source of authority for clients service discovery: clients connect to Sentinels in order to ask for the address of the current Redis master responsible for a given service. If a failover occurs, Sentinels will report the new address.

Sentinel可以作為配置中心，能夠提供當前主服務器的信息。

下面來具體講講Sentinel是如何將從服務器提升為主服務器的。

tips:Sentinel可以讓我們的Redis實現高可用，Sentinel作為這么一個組件，自身也必然是高可用的(不可能是單點的)

首先我們要知道的是：Sentinel本質上只是一個運行在特殊模式下的Redis服務器。因為Sentinel做的事情和Redis服務器是不一樣的，所以它們的初始化是有所區別的(比如，Sentinel在初始化的時候并不會載入AOF/RDB文件，因為Sentinel根本就不用數據庫)。

然后，在啟動的時候會將普通Redis服務器的代碼替換成Sentinel專用代碼。(所以Sentinel雖然作為Redis服務器，但是它不能執行SET、DBSIZE等等命令，因為命令表的代碼被替換了)

接著，初始化Sentinel的狀態，并根據給定的配置文件初始化Sentinel監視的主服務器列表。

最后，Sentinel會創建兩個連向主服務器的網絡連接：

命令連接(發送和接收命令)

訂閱連接(訂閱主服務器的_sentinel_:hello頻道)

Sentinel通過主服務器發送INFO命令來獲得主服務器屬下所有從服務器的地址信息，并為這些從服務器創建相應的實例結構。

當發現有新的從服務器出現時，除了創建對應的從服務器實例結構，Sentinel還會創建命令連接和訂閱連接。

在Sentinel運行的過程中，通過命令連接會以每兩秒一次的頻率向監視的主從服務器的_sentinel_:hello頻道發送命令(主要發送Sentinel本身的信息，監聽主從服務器的信息)，并通過訂閱連接接收_sentinel_:hello頻道的信息。

這樣一來一回，我們就可以更新每個Sentinel實例結構的信息。

判斷主服務器是否下線有兩種情況：

主觀下線

Sentinel會以每秒一次的頻率向與它創建命令連接的實例(包括主從服務器和其他的Sentinel)發送PING命令，通過PING命令返回的信息判斷實例是否在線

如果一個主服務器在down-after-milliseconds毫秒內連續向Sentinel發送無效回復，那么當前Sentinel就會主觀認為該主服務器已經下線了。

客觀下線

當Sentinel將一個主服務器判斷為主觀下線以后，為了確認該主服務器是否真的下線，它會向同樣監視該主服務器的Sentinel詢問，看它們是否也認為該主服務器是否下線。

如果足夠多的Sentinel認為該主服務器是下線的，那么就判定該主服務為客觀下線，并對主服務器執行故障轉移操作。

在多少毫秒內無效回復才認定主服務器是主觀下線的，以及有多少個Sentinel認為主服務器是下線才認定為客觀下線。這都是可以配置的

當一個主服務器認為為客觀下線以后，監視這個下線的主服務器的各種Sentinel會進行協商，選舉出一個領頭的Sentinel，領頭的Sentinel會對下線的主服務器執行故障轉移操作。

選舉領頭Sentinel的規則也比較多，總的來說就是先到先得(哪個快，就選哪個)

選舉出領頭的Sentinel之后，領頭的Sentinel會對已下線的主服務器執行故障轉移操作，包括三個步驟：

在已下線主服務器屬下的從服務器中，挑選一個轉換為主服務器

讓已下線主服務器屬下的所有從服務器改為復制新的主服務器

已下線的主服務器重新連接時，讓他成為新的主服務器的從服務器

(這三步實際上就是文章開頭的圖片)

挑選某一個從服務器作為主服務器也是有策略的，大概如下：

（1）跟master斷開連接的時長

（2）slave優先級

（3）復制offset

（4）run id

這篇文章主要講解了Sentinel的作用和工作的基本過程(我覺得已經基本OK了)，其中也涉及到了很多的細節，這里我就沒有一一整理出來了。想要深入學習的同學最好自己看看書或者文檔~~

tips:目前為止的主從+哨兵架構可以說Redis是高可用的，但要清楚的是：Redis還是會丟失數據的

丟失數據有兩種情況：

異步復制導致的數據丟失

有部分數據還沒復制到從服務器，主服務器就宕機了，此時這些部分數據就丟失了

腦裂導致的數據丟失

有時候主服務器脫離了正常網絡，跟其他從服務器不能連接。此時哨兵可能就會認為主服務器下線了(然后開啟選舉，將某個從服務器切換成了主服務器)，但是實際上主服務器還運行著。這個時候，集群里就會有兩個服務器(也就是所謂的腦裂)。

雖然某個從服務器被切換成了主服務器，但是可能客戶端還沒來得及切換到新的主服務器，客戶端還繼續寫向舊主服務器寫數據。舊的服務器重新連接時，會作為從服務器復制新的主服務器(這意味著舊數據丟失)。

可以通過以下兩個配置盡量減少數據丟失的可能：

min-slaves-to-write 1
min-slaves-max-lag 10

從零單排學Redis【鉑金三】，敬請期待~

參考資料：

《Redis設計與實現》

《Redis實戰》

如果你覺得我寫得還不錯，了解一下：

堅持原創的技術公眾號：Java3y。回復 1 加入Java交流群

文章的目錄導航(精美腦圖+海量視頻資源)：https://github.com/ZhongFuCheng3y/3y