上一節(jié)介紹了 Redis 主從復(fù)制, 我們知道主從架構(gòu)存在一個致命的問題----Master 宕機后整個集群不可用, 且必須運維人員手動進(jìn)行故障轉(zhuǎn)移.

因此, 哨兵來了

1. 哨兵模式(Sentinel)簡介

顧名思義, 哨兵 就是站崗、放哨、巡邏、稽查的士兵, 舉個例子, 就是當(dāng)你在干活時派幾個人盯著你, 看你有沒有偷懶, 有沒有累倒, 如果你累倒了重新派個人, 通知領(lǐng)導(dǎo)等等. Redis 哨兵模式 其實就是一個自動監(jiān)控、管理、處理 Redis 集群間故障的一個 Redis 服務(wù)端程序, 運行在一個特殊的模式下, 不提供數(shù)據(jù)存儲服務(wù), 只進(jìn)行普通 Redis 節(jié)點監(jiān)控管理等工作. 在哨兵模式中, 節(jié)點共分為兩大類:

• 數(shù)據(jù)節(jié)點(讀寫)

• 哨兵節(jié)點(監(jiān)控)

2. Sentinel 工作原理簡介

• 當(dāng) Master 宕機后, 整個集群將不可用(無法寫)

• 此時, 多個 Sentinel 會監(jiān)控并確認(rèn)到 Master 宕機, 因此多個 Sentinel 之間會進(jìn)行一次選舉, 選出一個 Sentinel 作為代表進(jìn)行故障轉(zhuǎn)移

• 當(dāng)選的 Sentinel 從剩余在線的所有 slave 節(jié)點中選舉一個 slave 作為新的 Master

• 通知所有的 Slave 新的 Master 地址, 通知所有的 Sentinel 新的 Master 地址, 并重新配置集群

3. Sentinel 作用

通過上面對 Sentinel 的簡單介紹, 相信大家已經(jīng)對 Sentinel 是干什么的有了一個基本的認(rèn)識, 概括來講, Sentinel 有如下作用:

• 監(jiān)控: Sentinel 會不斷檢查您的主實例和副本實例是否按預(yù)期工作。

• 通知: Sentinel 可以通過 API 通知系統(tǒng)管理員或其他計算機程序，其中一個受監(jiān)控的 Redis 實例出現(xiàn)問題。

• 自動故障轉(zhuǎn)移: 如果一個 master 沒有按預(yù)期工作，Sentinel 可以啟動一個故障轉(zhuǎn)移過程，其中一個副本被提升為 master，其他額外的副本被重新配置為使用新的 master，并且使用 Redis 服務(wù)器的應(yīng)用程序被告知要使用的新地址連接時。

• 配置提供者: Sentinel 充當(dāng)客戶端服務(wù)發(fā)現(xiàn)的權(quán)威來源：客戶端連接到 Sentinel 以請求負(fù)責(zé)給定服務(wù)的當(dāng)前 Redis 主服務(wù)器的地址。如果發(fā)生故障轉(zhuǎn)移，Sentinels 將報告新地址。

詳細(xì)可以參考官方文檔: https://redis.io/docs/manual/sentinel/#sentinel-as-a-distributed-system

4. Sentinel 實戰(zhàn)

4.1 服務(wù)器規(guī)劃

• 192.168.3.26: Master 實例, Sentinel 1

• 192.168.3.27: Slave1 實例, Sentinel 2

• 192.168.3.28:Slave2 實例, Sentinel 3

4.2 主從復(fù)制

主從復(fù)制的配置這里不再贅述, 還不清楚的朋友去參考上一節(jié) Redis 專題 Redis 集群-主從復(fù)制

4.3 啟動 Sentinel

啟動 Sentinel 這里還是以 Docker 為例(不建議大家在生產(chǎn)環(huán)境通過 Docker 部署, 具體問題可以參考官網(wǎng)Sentinel、Docker、NAT 可能的問題: https://redis.io/docs/manual/sentinel/#sentinel-docker-nat-and-possible-issues).

docker run -d --name sentinel1 -p 26379:26379 --restart=always \
   -v ${CONF_DIR}/redisSentinel1:/usr/local/etc/redis \
   -v ${LOGS_DIR}/redisSentinel1:/logs \
   -v ${VOLUME_DATA_DIR}/redisSentinel1:/data \
   redis redis-sentinel /usr/local/etc/redis/sentinel.conf

這里可以看到, 鏡像依然是 redis 的鏡像, 只不過有以下幾個改動:

• 端口從 6379 變?yōu)?26379 (配置文件可以改, 默認(rèn)為 26379)

• 運行命令從 redis-server 變?yōu)?redis-sentinel(運行在 sentinel mode)

• 配置文件從redis.conf 變?yōu)?sentinel.conf

4.4 配置 Sentinel

4.4.1 配置 Sentinel1

從上面啟動命令已經(jīng)看到, 要運行 sentinel 我們需要準(zhǔn)備一個 sentinel.conf 配置文件, 該文件對 sentinel mode 的 redis 實例進(jìn)行配置, 一個基本配置如下:

# 指定哨兵運行的端口
port 26379
# 為哨兵命名(mymaster), 192.168.3.26 監(jiān)控 redis 集群的主節(jié)點, 2(quorum) 表示有 2 個 sentinel 認(rèn)為某一個節(jié)點掛了就真的認(rèn)為它掛了(一般為 sentinel 集群數(shù) / 2 + 1)
sentinel monitor mymaster 192.168.3.26 6379 2
# 主節(jié)點多長時間沒響應(yīng)就認(rèn)為其掛了60000 == 60s
sentinel down-after-milliseconds mymaster 60000
# 新的 master 同步時一次有多少副本進(jìn)行同步(越小服務(wù)器壓力越小, 時間花費的越長)
sentinel parallel-syncs mymaster 1
# 數(shù)據(jù)同步超時時間
sentinel failover-timeout mymaster 180000

# Redis 實例密碼以確保 Sentinel 可以鏈接到 Redis 實例
sentinel auth-pass mymaster javaFamily123!!

# 允許其他人訪問
bind 0.0.0.0
protected-mode no

# 解決 docker 部署 ip 和端口重新映射的問題
sentinel announce-ip 192.168.3.26
sentinel announce-port 26379

運行起來 Sentinel 后會發(fā)現(xiàn) Sentinel 后臺有如下日志輸出

4.4.2 配置 Sentinel2 及 Sentinel3

配置 Sentinel2 及 Sentinel3 與 Sentinel1 基本類似, 只是在對應(yīng)機器上創(chuàng)建對應(yīng)的配置文件, 啟動 docker 即可

這里以 Sentinel2 為例說明

• sentinel.conf

# 指定哨兵運行的端口
port 26379
sentinel monitor mymaster 192.168.3.26 6379 2
sentinel auth-pass mymaster javaFamily123!!
sentinel down-after-milliseconds mymaster 60000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000

bind 0.0.0.0
protected-mode no

sentinel announce-ip 192.168.3.27
sentinel announce-port 26379

只需注意修改 sentinel announce-ip 為正確的 ip 即可.

• 啟動 sentinel2

docker run -d --name sentinel2 -p 26379:26379 --restart=always \
   -v ${CONF_DIR}/redisSentinel2:/usr/local/etc/redis \
   -v ${LOGS_DIR}/redisSentinel2:/logs \
   -v ${VOLUME_DATA_DIR}/redisSentinel2:/data \
   redis redis-sentinel /usr/local/etc/redis/sentinel.conf

4.4.3 查看 Sentinel 集群

• Sentinel 正常啟動后可以看到如下日志輸出

• 有時候也可以看到 sdown 及 odown 等標(biāo)記

其中 sdown 表示主觀下線, +sdown 表示新增主觀下線標(biāo)記, 以上截圖中意思為: sentinel1 主觀認(rèn)為 slave2(192.168.3.28) 下線了 如果認(rèn)為某一個節(jié)點下線的哨兵數(shù)量達(dá)到配置文件中配置的 quorum 數(shù)(我們是 3 個 sentinel 集群, quorum 配置的 2)就會標(biāo)記下線節(jié)點 +odown, 表示客觀下線 如果沒有達(dá)到 quorum, 即可能只是某個 sentinel 網(wǎng)絡(luò)原因認(rèn)為其主觀下線, 待網(wǎng)絡(luò)正常后就會取消主觀下線標(biāo)記, 即 -sdown

• Sentinel 正常啟動后也可以通過 redis-cli 指令連接到客戶端, 不過需要注意的是端口是 26379, 且 redis 運行在 Sentinel mode, 是不支持讀寫的

• 依然可以通過 info 指令查看 sentinel 狀態(tài), 不過在?sentinel mode 下會有一個 Sentinel 的信息板塊

4.5 測試故障轉(zhuǎn)移

為了測試 sentinel 的故障轉(zhuǎn)移, 我們直接手動停止 master 實例

我們需要等待 down-after-milliseconds mymaster(我們配置的 60s)后就可以在 sentinel 后臺看到如下信息:

4.6 測試新的主從

新的 master 已經(jīng)切換到 slave2(192.168.3.28), 副本為 slave1, 因此我們連接到新的 master 和 slave 測試是否依然高可用

• 連接新的 master(slave2) 寫入

• 連接 slave1 副本查詢

至此, Sentinel 已經(jīng)幫我們進(jìn)行了故障轉(zhuǎn)移, 整個 Redis 集群也達(dá)到了自動化高可用狀態(tài)

5. 哨兵的優(yōu)缺點

雖然 Sentinel 已經(jīng)彌補了主從的不足, 自動幫我們進(jìn)行故障轉(zhuǎn)移, 但是依然還存在一些問題

5.1 哨兵模式的優(yōu)點

• 哨兵集群，基于主從復(fù)制模式，所有的主從配置優(yōu)點，它都有

• 主從可以切換，故障可以轉(zhuǎn)移，高可用性的系統(tǒng)

• 哨兵模式就是主從模式的升級，手動到自動，更加健壯

• Sentinel 會不斷的檢查主服務(wù)器 和 從服務(wù)器是否正常運行。當(dāng)被監(jiān)控的某個 Redis 服務(wù)器出現(xiàn)問題，Sentinel 通過API腳本向管理員或者其他的應(yīng)用程序發(fā)送通知。

5.2 哨兵模式的缺點

• 單個節(jié)點的存儲能力是有上限的，訪問能力是有上限的, Redis 不好在線擴容，集群容量一旦到達(dá)上限，在線擴容就十分麻煩

• 每個節(jié)點都存儲著相同的數(shù)據(jù), 很浪費內(nèi)存

• 哨兵模式的配置繁瑣