在上篇文章我們學習了Redis教程——主從復制，這篇文章我們學習Redis教程——哨兵監控。

在主從復制中如果主機發生宕機，從機Redis會一直等到主機的恢復，這樣會導致只能進行讀操作，不能進行寫操作，這大大降低了系統的高可用性。為了解決這個問題，Redis提供了哨兵監控。

哨兵監控

哨兵監控是吹哨人巡查監控后臺主機Redis是否故障，如果故障了根據投票數自動將某個從機Redis轉換為新主機Redis，繼續對外服務。

如下圖所示：

這樣大大提高了Redis的高可用性。

通過哨兵監控，我們可以實現：

• 主從監控：監控主從Redis運行是否正常；

• 消息通知：哨兵可以將故障轉移的結果發送給客戶端；

• 故障轉移：如果主機Redis異常，則會進行主從切換，將其中一個從機Redis作為新主機Redis；

• 配置中心：客戶端通過連接哨兵來獲取當前Redis服務的主節點地址。

注意：哨兵一般是有多個，負責自動監控和維護集群，不存放數據。

配置文件

哨兵的默認配置文件為sentinel.conf，大家可以在Redis的安裝路徑中找到，在哨兵配置，通過如下圖配置項監聽主機Redis，

其配置項語法格式如下：

sentinel?monitor?<master-name>?<ip>?<redis-port>?<quorum>??#?設置監控的主機Redis服務器
sentinel?auth-pass?<master-name>?<password>?????????#?設置連接主機Redis服務的密碼

由于網絡是不可靠的，哨兵可能會因為網絡阻塞誤認為一個主機Redis發生宕機，所以一般情況下是有多個哨兵來監控Redis，互相溝通某個Redis是否真的發生宕機。

配置代碼中的quorum表示有多少個哨兵認為主機Redis發生宕機就進行從機Redis選舉新的主機Redis。

除了上面的兩條配置項，哨兵還有如下配置項，

sentinel?down-after-milliseconds?<master-name>?<milliseconds>??#?指定多少毫秒后，主機節點沒有應答哨兵，此時哨兵主觀上認為主節點下線
sentinel?parallel-syncs?<master-name>?<nums>??#?表示允許并行同步從機Redis個數，當主機Redis掛后，哨兵會選出新的主機Redis，此時，剩余的從機Redis會向新主機Redis發起同步數據
sentinel?failover-timeout?<master-name>?<milliseconds>??#?故障轉移超時時間，進行故障轉移時，如果超過設置的毫秒，表示故障轉移失敗
sentinel?notification-script?<master-name>?<script-path>??#?配置當某一個事件發生時所需要執行的腳步
sentinel?client-reconfig-script?<master-name>?<script-path>??#?客戶端重新配置主節點參數腳步

示例

配置

為了方便演示，我們準備了三臺服務器、三個哨兵，沒服務器的可以使用VMware虛擬機，如下圖所示：

這里我們已經配置好了主從關系，大家不懂怎么配置可以參考之前的文章：Redis教程——主從復制。

主機Redis有可能會變為從機，需要訪問新主機Redis的密碼，所以主機Redis配置也要添加masterauth配置項。

因為缺少足夠的服務器，我們把三個哨兵都配置在主機Redis的服務器中。

為了更直觀地查看哨兵的配置項，我們這里整理了目前所需的配置項，如下所示：

bind?0.0.0.0???#?服務監聽地址，用于客戶端連接
daemonize?yes???#?開啟哨兵
protected-mode?no??#?允許外界連接
port?26379????#?哨兵端口
logfile?"/myRedis/sentinel26379.log"??#?哨兵日志文件路徑
pidfile?/var/run/redis-sentinel26379.pid??#?哨兵pid文件
dir?/myRedis???????#?工作目錄
sentinel?monitor?mymaster?47.119.21.164?6379?2??#?設置監控的主機Redis服務器
sentinel?auth-pass?mymaster?123456???#?配置主機Redis的登錄密碼

由于三個哨兵都配置在同一個服務器中，所以不同哨兵的配置文件中端口號有所不同，所以上面的配置項中，port參數，哨兵日志、pid文件都需要稍微作調整。

最終我們在myRedis文件夾創建了三個哨兵配置文件，如下圖所示：

啟動哨兵

啟動哨兵有兩種方式：

redis-sentinel?哨兵配置文件路徑?--sentinel
redis-server?哨兵配置文件路徑?--sentinel

如下圖所示：

成功啟動哨兵后，會在你設置的哨兵日志文件路徑下生成日志文件，其中一個日志文件如下圖所示：

同時之前的哨兵配置文件也會發生變化，如下圖所示：

該新增的內容簡單來說就是哨兵已經知道了Redis主從關系并正在監聽Redis。

模擬主機宕機

通過關閉主機Redis的方式，模擬主機Redis發生宕機，發生宕機后，哨兵會在后臺進行一系列操作，所以這次的shutdown操作會延遲一下，如下圖所示：

主機Redis發生宕機后，從機Redis需要重新讀取網絡的規劃，所以從機Redis執行操作命令時，可能會報如下錯誤：

Error:?Server?closed?the?connection

我們只需稍微等待一下，錯誤就會自動消失。

接下來我們看哨兵日志文件，如下圖所示：

簡單來說，當主機Redis發生宕機后，一個哨兵主觀認為主機Redis宕機，多個哨兵進行投票后，客觀認為Redis已經宕機，接著選舉新主機Redis并確定主從關系。

在這個過程中，哨兵通過Raft算法選出一個哨兵為領導，推動新主機Redis的選舉、所有Redis配置文件、哨兵配置文件的修改。

Raft算法的基本思路是先到先得。

其中：

Redis配置文件將原來的replicaof配置項刪除或修改了，并在配置文件末尾添加了如下代碼：

#?Generated?by?CONFIG?REWRITE
latency-tracking-info-percentiles?50?99?99.9
save?3600?1
save?300?100
save?60?10000
user?default?on?#8d969eef6ecad3c29a3a629280e686cf0c3f5d5a86aff3ca12020c923adc6c92?~*?&*?+@all

該代碼主要是用于RDB持久化的配置。

原主機Redis末尾添加了如下代碼：

#?Generated?by?CONFIG?REWRITE
latency-tracking-info-percentiles?50?99?99.9
replicaof?111.230.32.139?6379
user?default?on?#8d969eef6ecad3c29a3a629280e686cf0c3f5d5a86aff3ca12020c923adc6c92?~*?&*?+@all

該代碼主要是用于配置主從關系，所以當原主機Redis恢復后，會變成新主機Redis的從機。

在哨兵配置文件中，主要對監聽的主機Redis服務器IP，主從關系做了修改，如下圖所示：

選舉原理

通過上面的內容，我們可以知道當一個主從配置中主機Redis失效后，哨兵會選舉出一個新的主機Redis來接替原主機Redis的工作。

選舉原理如下圖所示：

首先Redis配置文件中的slave-priority或replica-priority權限最高的Redis（數字越小優先級越高），如下圖所示：

優先級一樣高就對比復制數據的偏移量offset最大的從機Redis，偏移量一樣大就對比ID號，ID號最小的就成為新主機Redis。

選舉結束后，哨兵領導者會對選舉出來的新主機執行slaveof no one操作，將其提升為主機Redis，再向從機發送命令，讓剩余的從機成為新主機的從機，再讓原主機降級為從機并恢復正常工作。

好了，Redis教程——哨兵監控就講到這里。

公眾號：白巧克力LIN

該公眾號發布Python、數據庫、Linux、Flask、Django、自動化測試、Git、算法、前端、服務器等相關文章！

- END -