Sentinel介紹

Sentinel是Redis官方為集群提供的高可用解決方案。在實(shí)際項(xiàng)目中可以使用sentinel去做redis自動(dòng)故障轉(zhuǎn)移，減少人工介入的工作量。另外sentinel也給客戶端提供了監(jiān)控消息的通知，這樣客戶端就可根據(jù)消息類型去判斷服務(wù)器的狀態(tài)，去做對應(yīng)的適配操作。

下面是Sentinel主要功能列表：

• Monitoring：Sentinel持續(xù)檢查集群中的master、slave狀態(tài)，判斷是否存活。

• Notification：在發(fā)現(xiàn)某個(gè)redis實(shí)例死的情況下，Sentinel能通過API通知系統(tǒng)管理員或其他程序腳本。

• Automatic failover：如果一個(gè)master掛掉后，sentinel立馬啟動(dòng)故障轉(zhuǎn)移，把某個(gè)slave提升為master。其他的slave重新配置指向新master。

• Configuration provider：對于客戶端來說sentinel通知是有效可信賴的?？蛻舳藭B接sentinel去請求當(dāng)前master的地址，一旦發(fā)生故障sentinel會提供新地址給客戶端。

Sentinel配置

Sentinel本質(zhì)上只是一個(gè)運(yùn)行在特殊模式下的redis服務(wù)器，通過不同配置來區(qū)分提供服務(wù)。sentinel.conf配置：

// [監(jiān)控名稱] [ip] [port] [多少sentinel同意才發(fā)生故障轉(zhuǎn)移]
sentinel monitor mymaster 127.0.0.1 6379 2
// [監(jiān)控名稱] [Master多少毫秒后不回應(yīng)ping命令，就認(rèn)為master是主觀下線狀態(tài)]
sentinel down-after-milliseconds mymaster 60000
// [故障轉(zhuǎn)移超時(shí)時(shí)間]
sentinel failover-timeout mymaster 180000
//[在執(zhí)行故障轉(zhuǎn)移時(shí),最多可以有多少個(gè)從服務(wù)器同時(shí)對新的主服務(wù)器進(jìn)行同步]
sentinel parallel-syncs mymaster 1

sentinel需要使用redis2.8版本以上，啟動(dòng)如下：

redis-sentinel sentinel.conf

啟動(dòng)后Sentinel會：

• 以10秒一次的頻率，向被監(jiān)視的master發(fā)送info命令，根據(jù)回復(fù)獲取master當(dāng)前信息。

• 以1秒一次的頻率，向所有redis服務(wù)器、包含sentinel在內(nèi)發(fā)送PING命令，通過回復(fù)判斷服務(wù)器是否在線。

• 以2秒一次的頻率，通過向所有被監(jiān)視的master，slave服務(wù)器發(fā)送包含當(dāng)前sentinel，master信息的消息。

另外建議sentinel至少起3個(gè)實(shí)例以上，并配置2個(gè)實(shí)例同意即可發(fā)生轉(zhuǎn)移。5個(gè)實(shí)例，配置3個(gè)實(shí)例同意以此類推。

故障轉(zhuǎn)移消息接收的3種方式

Redis服務(wù)器一旦發(fā)送故障后，sentinel通過raft算法投票選舉新master。故障轉(zhuǎn)移過程可以通過sentinel的API獲取/訂閱接收事件消息。

搜索Java知音公眾號，回復(fù)“后端面試”，送你一份Java面試題寶典.pdf

腳本接收

• 當(dāng)故障轉(zhuǎn)移期間，可以指定一個(gè)“通知”腳本用來告知系統(tǒng)管理員，當(dāng)前集群的情況。
• 腳本被允許執(zhí)行的最大時(shí)間為60秒，如果超時(shí)，腳本將會被終止(KILL)

sentinel notification-script mymaster /var/redis/notify.sh 

• 故障轉(zhuǎn)移期之后，配置通知客戶端的腳本.

sentinel client-reconfig-script mymaster /var/redis/notifyReconfig.sh 

客戶端直接接收

Sentinel的故障轉(zhuǎn)移消息通知使用的是redis發(fā)布訂閱。就是說在故障轉(zhuǎn)移期間所有產(chǎn)生的事件信息，都通過頻道(channel)發(fā)布出去。比如我們加臺slave服務(wù)器，sentinel監(jiān)聽到后會發(fā)布加slave的消息到"+slave"頻道上，客戶端只需要訂閱"+slave"頻道即可接收到對應(yīng)消息。

其消息格式如下：
[實(shí)例類型] [事件服務(wù)器名稱] [服務(wù)器ip] [服務(wù)器端口] @[master名稱] [ip] [端口]

    @   

通知消息格式示例：

*          //訂閱類型， *即訂閱所有事件消息。
-sdown     //消息類型
slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6381

訂閱消息示例：

using (RedisSentinel rs = new RedisSentinel(CurrentNode.Host, CurrentNode.Port))
            {
                var redisPubSub = new RedisPubSub(node.Host, node.Port);
                redisPubSub.OnMessage += OnMessage;
                redisPubSub.OnSuccess += (msg) =>{};
                redisPubSub.OnUnSubscribe += (obj) =>{};
                redisPubSub.OnError = (exception) =>{ };
                redisPubSub.PSubscribe("*");
            }

服務(wù)間接接收

這種方式在第二種基礎(chǔ)上擴(kuò)展了一層，即應(yīng)用端不直接訂閱sentinel。單獨(dú)做服務(wù)去干這件事情，然后應(yīng)用端提供API供這個(gè)服務(wù)回調(diào)通知。這樣做的好處在于：

• 減少應(yīng)用端監(jiān)聽失敗出錯(cuò)的可能性。

• 應(yīng)用端由主動(dòng)方變成被動(dòng)方，降低耦合。

• 性能提高，輪詢變回調(diào)。

• 獨(dú)立成服務(wù)可擴(kuò)展性更高。

比如：

1：以后換掉sentinel，我們只需要?jiǎng)臃?wù)即可，應(yīng)用端無需更改。

2：可以在服務(wù)內(nèi)多增加一層守護(hù)線程去主動(dòng)拉取redis狀態(tài)，這樣可確保即使sentinel不生效，也能及時(shí)察覺redis狀態(tài)，并通知到應(yīng)用端。當(dāng)然這種情況很極端，因?yàn)閟entinel配的也是多節(jié)點(diǎn)，同時(shí)掛的幾率非常小。

示例：

應(yīng)用端提供回調(diào)API，在這個(gè)API邏輯下去刷新內(nèi)存中的Redis連接。

http://127.0.0.1/redis/notify.api

獨(dú)立服務(wù)監(jiān)控到狀況后，調(diào)用API通知應(yīng)用端：

 httprequest.post("http://127.0.0/redis/notify.api");

整體設(shè)計(jì)

推薦使用第三種，其整體流程圖如下：