Redis低成本高可用方案設(shè)計(jì)
? ? ?
? ?正文? ?
關(guān)于Redis高可用方案,看到較多的是keepalived、zookeeper方案。keepalived是主備模式,意味著總有一臺(tái)浪費(fèi)著。zookeeper工作量成本偏高。
本文主要介紹下使用官方sentinel做redis高可用方案的設(shè)計(jì)。
閱讀目錄:
Redis Sentinel
故障轉(zhuǎn)移消息接收的3種方式
整體流程圖
總結(jié)
Redis Sentinel
Sentinel介紹
Sentinel是Redis官方為集群提供的高可用解決方案。在實(shí)際項(xiàng)目中可以使用sentinel去做redis自動(dòng)故障轉(zhuǎn)移,減少人工介入的工作量。另外sentinel也給客戶(hù)端提供了監(jiān)控消息的通知,這樣客戶(hù)端就可根據(jù)消息類(lèi)型去判斷服務(wù)器的狀態(tài),去做對(duì)應(yīng)的適配操作。
下面是Sentinel主要功能列表:
Monitoring:Sentinel持續(xù)檢查集群中的master、slave狀態(tài),判斷是否存活。
Notification:在發(fā)現(xiàn)某個(gè)redis實(shí)例死的情況下,Sentinel能通過(guò)API通知系統(tǒng)管理員或其他程序腳本。
Automatic failover:如果一個(gè)master掛掉后,sentinel立馬啟動(dòng)故障轉(zhuǎn)移,把某個(gè)slave提升為master。其他的slave重新配置指向新master。
Configuration provider:對(duì)于客戶(hù)端來(lái)說(shuō)sentinel通知是有效可信賴(lài)的。客戶(hù)端會(huì)連接sentinel去請(qǐng)求當(dāng)前master的地址,一旦發(fā)生故障sentinel會(huì)提供新地址給客戶(hù)端。
Sentinel配置
Sentinel本質(zhì)上只是一個(gè)運(yùn)行在特殊模式下的redis服務(wù)器,通過(guò)不同配置來(lái)區(qū)分提供服務(wù)。sentinel.conf配置:
//?[監(jiān)控名稱(chēng)]?[ip]?[port]?[多少sentinel同意才發(fā)生故障轉(zhuǎn)移]
sentinel?monitor?mymaster?127.0.0.1?6379?2
//?[監(jiān)控名稱(chēng)]?[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í)對(duì)新的主服務(wù)器進(jìn)行同步]
sentinel?parallel-syncs?mymaster?1
sentinel需要使用redis2.8版本以上,啟動(dòng)如下:
redis-sentinel?sentinel.conf
啟動(dòng)后Sentinel會(huì):
以10秒一次的頻率,向被監(jiān)視的master發(fā)送info命令,根據(jù)回復(fù)獲取master當(dāng)前信息。
以1秒一次的頻率,向所有redis服務(wù)器、包含sentinel在內(nèi)發(fā)送PING命令,通過(guò)回復(fù)判斷服務(wù)器是否在線。
以2秒一次的頻率,通過(guò)向所有被監(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í)例同意以此類(lèi)推。
故障轉(zhuǎn)移消息接收的3種方式
Redis服務(wù)器一旦發(fā)送故障后,sentinel通過(guò)raft算法投票選舉新master。故障轉(zhuǎn)移過(guò)程可以通過(guò)sentinel的API獲取/訂閱接收事件消息。
腳本接收
當(dāng)故障轉(zhuǎn)移期間,可以指定一個(gè)“通知”腳本用來(lái)告知系統(tǒng)管理員,當(dāng)前集群的情況。 腳本被允許執(zhí)行的最大時(shí)間為60秒,如果超時(shí),腳本將會(huì)被終止(KILL)
sentinel?notification-script?mymaster?/var/redis/notify.sh?
故障轉(zhuǎn)移期之后,配置通知客戶(hù)端的腳本.
sentinel?client-reconfig-script?mymaster?/var/redis/notifyReconfig.sh?
客戶(hù)端直接接收
Sentinel的故障轉(zhuǎn)移消息通知使用的是redis發(fā)布訂閱。就是說(shuō)在故障轉(zhuǎn)移期間所有產(chǎn)生的事件信息,都通過(guò)頻道(channel)發(fā)布出去。比如我們加臺(tái)slave服務(wù)器,sentinel監(jiān)聽(tīng)到后會(huì)發(fā)布加slave的消息到"+slave"頻道上,客戶(hù)端只需要訂閱"+slave"頻道即可接收到對(duì)應(yīng)消息。
其消息格式如下:
[實(shí)例類(lèi)型] [事件服務(wù)器名稱(chēng)] [服務(wù)器ip] [服務(wù)器端口] @[master名稱(chēng)] [ip] [端口]
????@???
通知消息格式示例:
*??????????//訂閱類(lèi)型,?*即訂閱所有事件消息。
-sdown?????//消息類(lèi)型
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)聽(tīng)失敗出錯(cuò)的可能性。
應(yīng)用端由主動(dòng)方變成被動(dòng)方,降低耦合。
性能提高,輪詢(xún)變回調(diào)。
獨(dú)立成服務(wù)可擴(kuò)展性更高。
比如:
1:以后換掉sentinel,我們只需要?jiǎng)臃?wù)即可,應(yīng)用端無(wú)需更改。
2:可以在服務(wù)內(nèi)多增加一層守護(hù)線程去主動(dòng)拉取redis狀態(tài),這樣可確保即使sentinel不生效,也能及時(shí)察覺(jué)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ì)
推薦使用第三種,其整體流程圖如下:

總結(jié)
各種sentinel通知消息類(lèi)型見(jiàn)官方文檔,項(xiàng)目中使用的redis客戶(hù)端在github上
https://github.com/mushroomsir/HRedis
本文分享了樓主在項(xiàng)目中做Redis高可用的經(jīng)驗(yàn),希望對(duì)大家有所幫助。在人力物力滿(mǎn)足的情況下還是推薦使用zookeeper方案的。只有三五桿槍的情況下也就退而求其次,利用最小成本滿(mǎn)足需求并保留可擴(kuò)展性。?
相信沒(méi)有最好的架構(gòu),只有更合適的架構(gòu)。
http://redis.io/topics/sentinel
來(lái)源:cnblogs.com/mushroom/p/4526912.html
版權(quán)申明:內(nèi)容來(lái)源網(wǎng)絡(luò),版權(quán)歸原創(chuàng)者所有。除非無(wú)法確認(rèn),我們都會(huì)標(biāo)明作者及出處,如有侵權(quán)煩請(qǐng)告知,我們會(huì)立即刪除并表示歉意。謝謝!

