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

只有光頭才能變強

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

從零單排學(xué)Redis【青銅】

從零單排學(xué)Redis【白銀】

從零單排學(xué)Redis【黃金】

從零單排學(xué)Redis【鉑金一】

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

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

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

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

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

主服務(wù)器掛了，主從復(fù)制操作就中止了，并且哨兵系統(tǒng)是可以察覺出主服務(wù)掛了。：

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

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

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

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

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

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

Sentinel不停地監(jiān)控Redis主從服務(wù)器是否正常工作

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實例有故障，那么哨兵負(fù)責(zé)發(fā)送消息通知管理員

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.

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

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可以作為配置中心，能夠提供當(dāng)前主服務(wù)器的信息。

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

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

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

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

接著，初始化Sentinel的狀態(tài)，并根據(jù)給定的配置文件初始化Sentinel監(jiān)視的主服務(wù)器列表。

最后，Sentinel會創(chuàng)建兩個連向主服務(wù)器的網(wǎng)絡(luò)連接：

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

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

Sentinel通過主服務(wù)器發(fā)送INFO命令來獲得主服務(wù)器屬下所有從服務(wù)器的地址信息，并為這些從服務(wù)器創(chuàng)建相應(yīng)的實例結(jié)構(gòu)。

當(dāng)發(fā)現(xiàn)有新的從服務(wù)器出現(xiàn)時，除了創(chuàng)建對應(yīng)的從服務(wù)器實例結(jié)構(gòu)，Sentinel還會創(chuàng)建命令連接和訂閱連接。

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

這樣一來一回，我們就可以更新每個Sentinel實例結(jié)構(gòu)的信息。

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

主觀下線

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

如果一個主服務(wù)器在down-after-milliseconds毫秒內(nèi)連續(xù)向Sentinel發(fā)送無效回復(fù)，那么當(dāng)前Sentinel就會主觀認(rèn)為該主服務(wù)器已經(jīng)下線了。

客觀下線

當(dāng)Sentinel將一個主服務(wù)器判斷為主觀下線以后，為了確認(rèn)該主服務(wù)器是否真的下線，它會向同樣監(jiān)視該主服務(wù)器的Sentinel詢問，看它們是否也認(rèn)為該主服務(wù)器是否下線。

如果足夠多的Sentinel認(rèn)為該主服務(wù)器是下線的，那么就判定該主服務(wù)為客觀下線，并對主服務(wù)器執(zhí)行故障轉(zhuǎn)移操作。

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

當(dāng)一個主服務(wù)器認(rèn)為為客觀下線以后，監(jiān)視這個下線的主服務(wù)器的各種Sentinel會進行協(xié)商，選舉出一個領(lǐng)頭的Sentinel，領(lǐng)頭的Sentinel會對下線的主服務(wù)器執(zhí)行故障轉(zhuǎn)移操作。

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

選舉出領(lǐng)頭的Sentinel之后，領(lǐng)頭的Sentinel會對已下線的主服務(wù)器執(zhí)行故障轉(zhuǎn)移操作，包括三個步驟：

在已下線主服務(wù)器屬下的從服務(wù)器中，挑選一個轉(zhuǎn)換為主服務(wù)器

讓已下線主服務(wù)器屬下的所有從服務(wù)器改為復(fù)制新的主服務(wù)器

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

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

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

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

（2）slave優(yōu)先級

（3）復(fù)制offset

（4）run id

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

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

丟失數(shù)據(jù)有兩種情況：

異步復(fù)制導(dǎo)致的數(shù)據(jù)丟失

有部分?jǐn)?shù)據(jù)還沒復(fù)制到從服務(wù)器，主服務(wù)器就宕機了，此時這些部分?jǐn)?shù)據(jù)就丟失了

腦裂導(dǎo)致的數(shù)據(jù)丟失

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

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

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

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

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

參考資料：

《Redis設(shè)計與實現(xiàn)》

《Redis實戰(zhàn)》

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

堅持原創(chuàng)的技術(shù)公眾號：Java3y。回復(fù) 1 加入Java交流群

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