1. 引言

之前我們聊過 Redis 的主從同步（復(fù)制）主題，這期我們來聊 Redis 的哨兵機制。

上期我們說過，在實際互聯(lián)網(wǎng)架構(gòu)上，Redis 為了保證高可用和分擔(dān)讀寫壓力，幾乎都會采取主從復(fù)制的部署架構(gòu)。

一方面讓架構(gòu)易于擴展，另一方面防止單體故障：當(dāng)主庫掛了，可以立即拉起從庫，不至于讓業(yè)務(wù)停滯太久。

江湖門派林立

如果把所有互聯(lián)網(wǎng)應(yīng)用看做是一個江湖，Redis 是武林中的門派，為了讓門派更加穩(wěn)定，每個門派都有掌門和副掌門。

在一些小門派里面，掌門仙逝以后，都會開追悼大會，然后從副掌門中再選一個掌門出來主持大局，這個過程可能會持續(xù)好幾天。

但是，在一些大門派里面，比如武林之中一些有名望的派別：武當(dāng)、少林（如淘寶、微信）之流，卻不可一日無掌門。

放到如今的雙 11，電商應(yīng)用掛幾秒鐘可能都是千萬甚至億萬級別的損失，所以對系統(tǒng)的可用性要求非常高。

一般大型應(yīng)用的可用性都需要達到 4 個 9：即 99.99%，一年宕機時間不超過 53 分鐘。

那以武當(dāng)（淘寶 Redis）為例，需要如何保證門派的穩(wěn)定性呢？

首先我們得依賴副掌門機制（主從復(fù)制）做備份，上篇我們已經(jīng)說過了。

這期我們來說一下在掌門掛了后如何高效交接事務(wù)（故障轉(zhuǎn)移），武林門派大會 2.8 后，每個門派有一個單獨的部門來負責(zé)掌門交接事宜——哨兵部門。

Redis2.8 版本以后提供的哨兵機制（Sentinel）。

2. 哨兵部門的職責(zé)

在武當(dāng)派，張真人之下有武當(dāng)七俠，從聲望和資歷來看，派內(nèi)將前兩位弟子作為副掌門人選，他們平時也會輔助掌門處理門派事務(wù)。

而哨兵部門的職責(zé)，主要有四點：

圖片

• 監(jiān)控：檢查掌門和副掌門狀態(tài)，查看他們的生命體征和情緒狀態(tài)是否正常；
• 自動故障轉(zhuǎn)移：當(dāng)掌門人閉關(guān)或者嗝屁了后，立馬從副掌門選一個新掌門接手門派事務(wù)；
• 配置提供者：外賓（客戶端）來訪時，通過哨兵部門來獲取掌門人的聯(lián)系方式；
• 通知：掌門更換以后，哨兵部門將新掌門已更新的信息發(fā)布到外界。

其中監(jiān)控和故障轉(zhuǎn)移功能主要是為了維系系統(tǒng)的穩(wěn)定，可以第一時間感知幾位掌門的狀態(tài)，當(dāng)掌門人閉關(guān)或者嗝屁以后，能快速地選出一個新的掌門接替門派事務(wù)。

而配置提供和通知功能主要是和客戶端交互，可以理解為哨兵部門是外賓和門派建立聯(lián)系的橋梁。

并且，當(dāng)掌門人易主以后，哨兵機制會向客戶端發(fā)布新的主節(jié)點地址。仿佛在向外界宣布，新掌門聯(lián)系方式變了，望周知！

3. 哨兵部門如何工作

哨兵部門這么強橫，那它究竟是怎么做到的呢？接下來我們從分別從監(jiān)控、節(jié)點切換、發(fā)布通知和節(jié)點恢復(fù)來詳細介紹一下。

3.1 監(jiān)控-感知各掌門的狀態(tài)

雖然說是監(jiān)控，但哨兵只是對各掌門人的狀態(tài)是否正常做一個判斷，門派事務(wù)哨兵是一概不參與的（畢竟人家是掌門&副掌門，哨兵還管不著這么寬）！

在武當(dāng)派，不管是哨兵部門的成員，還是副掌門之上，都會一招 “千里傳音”，以便更好地傳遞事務(wù)消息。

那既然不能參與事務(wù)，哨兵如何監(jiān)控它們的狀態(tài)呢？

圖片

如圖所示，哨兵成員會定期給掌門人們千里傳音，各掌門如果定時回復(fù)，那掌門人就處于正常狀態(tài)。

反之，如果掌門在規(guī)定時間內(nèi)不回復(fù)就說明狀態(tài)不正常，哨兵就會采取行動。

主觀下線

在 Redis 服務(wù)器中，哨兵每隔 1 秒會給主從節(jié)點發(fā)送 PING 命令，如果在一定時間內(nèi)收到響應(yīng)，就說明節(jié)點正常運行。

如果任意一個主/從節(jié)點沒有在規(guī)定時間內(nèi)（down-after-milliseconds 可配置，單位是毫秒）響應(yīng)，哨兵就認為這個節(jié)點掛了，將其標(biāo)記為主觀下線。

為什么是主觀下線呢？

因為 Redis 中為了保證監(jiān)控的穩(wěn)定性，當(dāng)一個哨兵沒收到回復(fù)時，就說明這個節(jié)點有概率掛了，但是不一定完全是節(jié)點的問題，也有可能是網(wǎng)絡(luò)故障，或者阻塞了導(dǎo)致消息沒有正常傳播。

在武當(dāng)，哨兵部門就出過洋相！

那天，某個哨兵監(jiān)控到掌門人長時間不回復(fù)消息，于是主觀判斷掌門人嗝屁了。于是開始換掌門，發(fā)通知，一頓操作下來，掌門人又傳來回復(fù)說晚飯吃得有點飽，千里傳音可能聲音比較小，哨兵沒聽到。

這讓武林同道看盡了笑話，至今傳為茶余飯后的談資。

客觀下線

于是，為了防止這種情況的發(fā)生，哨兵部門決定加派人手，每個部門至少 3 個人，每次判斷掌門嗝屁時如果有多個人得出相同的判斷，才能說明這個判斷有效。

在 Redis 里，每次部署哨兵集群時至少三臺機器來部署，當(dāng)某個哨兵判斷節(jié)點主觀下線后，就會向其它哨兵發(fā)起命令，其它哨兵根據(jù)自己的監(jiān)控情況，給出贊同或者反對的投票。

圖片

當(dāng)多數(shù)節(jié)點（比如 3 個哨兵有 2 個都認可，quorum 可配置這個值）支持節(jié)點已下線，該節(jié)點會被標(biāo)記為客觀下線。

當(dāng)判斷主節(jié)點客戶下線后，哨兵機制會進行故障轉(zhuǎn)移操作，即選出一個從節(jié)點升級為主節(jié)點。

不難理解，如果掌門人掛了，則哨兵部門會重新選一個新的掌門，來接替門派事務(wù)。

3.2 節(jié)點切換：如何選出新掌門

領(lǐng)頭哨兵：主持掌門更換儀式

首先，哨兵部門會先選一個領(lǐng)頭哨兵（leader sentinel），來主持換掌門的儀式。

圖片

領(lǐng)頭哨兵的選舉需要從領(lǐng)頭候選人（leader candidate）里面選，而只有發(fā)現(xiàn)掌門客觀下線的哨兵成員才可以成為候選人。

通過所有哨兵節(jié)點給候選人投票，至少得票數(shù)過半的候選人才能成為領(lǐng)頭哨兵。

為了防止票數(shù)重疊（刷票行為），每個節(jié)點只可以投一票，并且當(dāng)節(jié)點成為哨兵候選人時，會首先給自己投一票。

不難理解，畢竟換掌門儀式和下任新掌門息息相關(guān)，所以每個哨兵都想當(dāng)這個 leader。

在 Redis 里面，參選領(lǐng)頭哨兵的候選人不止需要拿到半數(shù)以上的票，還需要超過配置文件中的 quorum 值才可以成為 leader sentinel。

為了防止投票數(shù)一致的問題，哨兵個數(shù)和 Redis 的節(jié)點數(shù)一樣，一般為單數(shù)個。

主從故障轉(zhuǎn)移：選出新掌門

哨兵集群中選出一個 leader哨兵 之后，就開始進行主從故障轉(zhuǎn)移。

在武當(dāng)，老掌門掛了，誰來當(dāng)這個新掌門呢？

為了公平起見，哨兵部門制定了一個策略，會從副掌門的向上管理能力、業(yè)務(wù)熟悉程度以及資歷來考慮。

對應(yīng) Redis 里選主節(jié)點的三大策略：優(yōu)先級、復(fù)制進度、節(jié)點 ID 號。

1. 優(yōu)先級

哨兵會根據(jù)從節(jié)點的優(yōu)先級進行排序，優(yōu)先級越小排名越靠前。

在門派中，這可能是看哪個副掌門的向上管理做得更好，和領(lǐng)導(dǎo)走得更近，畢竟，掌門在選接班人時也會有優(yōu)先級的側(cè)重。

2. 復(fù)制進度

如果節(jié)點的優(yōu)先級不分上下，則查看數(shù)據(jù)復(fù)制的 slave_repl_offset 參數(shù)，這個參數(shù)指向了從節(jié)點復(fù)制數(shù)據(jù)的偏移量，偏移量越大（復(fù)制數(shù)據(jù)越多）的那個從節(jié)點勝出。

想了解更多的，可以看我上一篇文章：救命！只有我還不明白Redis主從復(fù)制的原理嗎？

這就好比掌門不偏不倚，對待副掌門都一視同仁。這就得考量副掌門的業(yè)務(wù)熟悉能力了，誰在掌門那里學(xué)的本事越多，誰就來當(dāng)這個新掌門。

3. 節(jié)點 ID 號

當(dāng)優(yōu)先級和復(fù)制程度都相同時，就選擇從節(jié)點 ID 較小的那個（說明排行越高）。

當(dāng)副掌門的受重視程度和能力不相上下時，就得論資排輩了，看誰資歷更高，排行更靠前（大師兄 > 二師兄 > 三師弟），誰就來當(dāng)這個新掌門。

3.3 通知機制：更換掌門后告知武林同道

在哨兵機制的協(xié)助下，從節(jié)點晉升為主節(jié)點，這時機器節(jié)點的 IP 等信息都更換了，所以需要知會客戶端和新的主節(jié)點進行通信，這是通過發(fā)布/訂閱者機制實現(xiàn)的。

圖片

每個門派可能有諸多事宜，但是客戶端（外賓）不會關(guān)心所有的事件，它們只關(guān)心一些像掌門更換這種大事情。

在 Redis 里面，哨兵機制提供的訂閱事件主要有如下三種：

1. 主節(jié)點下線事件：如節(jié)點主觀下線（+sdown）、客觀下線（+odown）等；
2. 從庫更新配置事件：如重新同步（+slave-reconf-sent）、主從同步完成（+slave-reconf-done）等；
3. 主節(jié)點更換：主庫地址發(fā)生變化（+switch-master）。

如果客戶端訂閱了主節(jié)點更換的事件，就會收到哨兵的通知事件，進而調(diào)整自身連接的節(jié)點信息。

3.4 節(jié)點恢復(fù)：老掌門出關(guān)，擔(dān)任副掌門

所謂一山不容二虎，哨兵部門在更換掌門后要做的職責(zé)是，繼續(xù)監(jiān)控老掌門的體征信息。

圖片

一當(dāng)老掌門有消息回復(fù)時，哨兵部門就會告訴它，現(xiàn)在已經(jīng)有新掌門人了，老掌門失聯(lián)這么久，對門派事務(wù)的了解難免落后，所以會讓它先擔(dān)任副掌門。

Redis 中，哨兵集群會向重新上線的舊主節(jié)點發(fā)送 SLAVEOF 命令，讓它成為新主節(jié)點的從節(jié)點。

當(dāng)哨兵集群同步這個事件以后，會接著發(fā)布從庫更新配置事件的訂閱消息，讓客戶端也知曉。

4. 小結(jié)

在大型的互聯(lián)網(wǎng)應(yīng)用上，Redis 為了保證高可用，會在主從復(fù)制的部署架構(gòu)上進一步引入哨兵機制。

如果說主從同步是 Redis 高可用的數(shù)據(jù)保障基礎(chǔ)，那哨兵機制就是 Redis 高可用的進階支撐，有了它，就不用擔(dān)心 Redis 掛了后得人工升級，并且還非常低效的問題了。

畢竟，亂世江湖，門派中一旦群龍無首，就很容易陷入危機，導(dǎo)致四分五裂！

接下來我們總結(jié)一下，哨兵機制的工作流程：

1. 監(jiān)控各節(jié)點狀態(tài)，判斷是否下線（千里傳音，了解各掌門狀態(tài)）；
2. 當(dāng)主節(jié)點主觀下線以后，選出一個領(lǐng)頭哨兵做故障轉(zhuǎn)移（掌門人掛了，選一個leader主持掌門更換儀式）；
3. 選出一個從節(jié)點，晉升為從節(jié)點，并發(fā)布通知（選出新掌門，向武林同道發(fā)布這個消息）；
4. 繼續(xù)監(jiān)控，如果老節(jié)點恢復(fù)，就讓它作為新主節(jié)點的備份從節(jié)點（老掌門出關(guān)，先給個副掌門當(dāng)當(dāng)）。

而 Redis 精準(zhǔn)無誤地執(zhí)行上述流程，是通過發(fā)布訂閱、投票算法等機制做到的，這讓系統(tǒng)的高可用進一步得到了保障。

在派系林立的江湖也這樣，哨兵部門如果能很好地處理掌門人之間的權(quán)力和事務(wù)關(guān)系，門派發(fā)展擴大亦是指日可待！