《Redis 備份、容災及高可用實戰(zhàn)》要點:
本文介紹了Redis 備份、容災及高可用實戰(zhàn),希望對您有用。如果有疑問,可以聯系我們。

作者介紹
郝朝陽,宜搜科技,運維工程師,負責前端運維工作.專注于運維自動化的實現.致力于DevOps思想的推廣,幫助企業(yè)形成形成自有文化的運維體系建設.
一、Redis簡單介紹
Redis是一個高性能的key-value非關系型數據庫,由于其具有高性能的特性,支持高可用、持久化、多種數據結構、集群等,使其脫穎而出,成為常用的非關系型數據庫.
此外,Redis的使用場景也比較多.
- 會話緩存(Session Cache)
Redis緩存會話有非常好的優(yōu)勢,因為Redis提供持久化,在需要長時間保持會話的應用場景中,如購物車場景這樣的場景中能提供很好的長會話支持,能給用戶提供很好的購物體驗.
- 全頁緩存
在WordPress中,Pantheon提供了一個不錯的插件wp-redis
,這個插件能以最快的速度加載你曾經瀏覽過的頁面.
- 隊列
Reids提供list和set操作,這使得Redis能作為一個很好的消息隊列平臺來使用.我們常通過Reids的隊列功能做購買限制.比如到節(jié)假日或者推廣期間,進行一些活動,對用戶購買行為進行限制,限制今天只能購買幾次商品或者一段時間內只能購買一次.也比較適合適用.
- 排名
Redis在內存中對數字進行遞增或遞減的操作實現得非常好.所以我們在很多排名的場景中會應用Redis來進行,比如小說網站對小說進行排名,根據排名,將排名靠前的小說推薦給用戶.
- 發(fā)布/訂閱
Redis提供發(fā)布和訂閱功能,發(fā)布和訂閱的場景很多,比如我們可以基于發(fā)布和訂閱的腳本觸發(fā)器,實現用Redis的發(fā)布和訂閱功能建立起來的聊天系統(tǒng).
此外還有很多其它場景,Redis都表現的不錯.
二、Redis使用中單點故障問題
正是由于Redis具備多種優(yōu)良特新,且應用場景非常豐富,以至于Redis在各個公司都有它存在的身影.那么隨之而來的問題和風險也就來了.Redis雖然應用場景豐富,但部分公司在實踐Redis應用的時候還是相對保守使用單節(jié)點部署,那為日后的維護帶來了安全風險.
在2015年的時候,曾處理過一個因為單點故障原因導致的業(yè)務中斷問題.當時的Redis都未采用分布式部署,采用單實例部署,并未考慮容災方面的問題.
當時我們通過Redis服務器做用戶購買優(yōu)惠商品的行為控制,但后來由于未知原因Redis節(jié)點的服務器宕機了,導致我們無法對用戶購買行為進行控制,造成了用戶能夠在一段時間內多次購買優(yōu)惠商品的行為.
這種宕機事故可以說已經對公司造成了不可挽回的損失了,安全風險問題非常嚴重,作為當時運維這個系統(tǒng)的我來說有必要對這個問題進行修復和在架構上的改進.于是我開始了解決非分布式應用下Redis單點故障方面的研究學習.
三、非分布式場景下Redis應用的備份與容災
Redis主從復制現在應該是很普遍了.常用的主從復制架構有如下兩種架構方案.
常用Redis主從復制
這是最常見的一種架構,一個Master節(jié)點,兩個Slave節(jié)點.客戶端寫數據的時候是寫Master節(jié)點,讀的時候,是讀取兩個Slave,這樣實現讀的擴展,減輕了Master節(jié)點讀負載.

- 這種架構同樣是一個Master和兩個Slave.不同的是Master和Slave1使用keepalived進行VIP轉移.Client連接Master的時候是通過VIP進行連接的.避免了方案一IP更改的情況.
Redis主從復制優(yōu)點與不足
- 實現了對master數據的備份,一旦master出現故障,slave節(jié)點可以提升為新的master,頂替舊的master繼續(xù)提供服務
- 實現讀擴展.使用主從復制架構, 一般都是為了實現讀擴展.Master主要實現寫功能, ?Slave實現讀的功能
- 不足
架構方案一
當Master出現故障時,Client就與Master端斷開連接,無法實現寫功能,同時Slave也無法從Master進行復制.

此時需要經過如下操作(假設提升Slave1為Master):
- 在Slave1上執(zhí)slaveof no one命令提升Slave1為新的Master節(jié)點.
- 在Slave1上配置為可寫,這是因為大多數情況下,都將slave配置只讀.
- 告訴Client端(也就是連接Redis的程序)新的Master節(jié)點的連接地址.
- 配置Slave2從新的Master進行數據復制.
架構方案二
當master出現故障后,Client可以連接到Slave1上進行數據操作,但是Slave1就成了一個單點,就出現了經常要避免的單點故障(single point of failure).

之后需要經過如下操作:
- 在Slave1上執(zhí)行slaveof no one命令提升Slave1為新的Master節(jié)點
- 在Slave1上配置為可寫,這是因為大多數情況下,都將Slave配置只讀
- 配置Slave2從新的Master進行數據復制
可以發(fā)現,無論是哪種架構方案都需要人工干預來進行故障轉移(failover).需要人工干預就增加了運維工作量,同時也對業(yè)務造成了巨大影響.這時候可以使用Redis的高可用方案-Sentinel
四、Redis Sentinel介紹
Redis Sentinel為Redis提供了高可用方案.從實踐方面來說,使用Redis Sentinel可以創(chuàng)建一個無需人為干預就可以預防某些故障的Redis環(huán)境.
Redis Sentinel設計為分布式的架構,運行多個Sentinel進程來共同合作的.運行多個Sentinel進程合作,當多個Sentinel同一給定的master無法再繼續(xù)提供服務,就會執(zhí)行故障檢測,這會降低誤報的可能性.
五、Redis Sentinel功能
Redis Sentinel在Redis高可用方案中主要作用有如下功能:
- 監(jiān)控
Sentinel會不斷的檢查master和slave是否像預期那樣正常運行
- 通知
通過API,Sentinel能夠通知系統(tǒng)管理員、程序監(jiān)控的Redis實例出現了故障
- 自動故障轉移
如果master不像預想中那樣正常運行,Sentinel可以啟動故障轉移過程,其中的一個slave會提成為master,其它slave會重新配置來使用新的master,使用Redis服務的應用程序,當連接時,也會被通知使用新的地址.
- 配置提供者
Sentinel可以做為客戶端服務發(fā)現的認證源:客戶端連接Sentinel來獲取目前負責給定服務的Redis master地址.如果發(fā)生故障轉移,Sentinel會報告新的地址.
六、Redis Sentinel架構

七、Redis Sentinel實現原理
Sentinel集群對自身和Redis主從復制進行監(jiān)控.當發(fā)現Master節(jié)點出現故障時,會經過如下步驟:
- 1)Sentinel之間進行選舉,選舉出一個leader,由選舉出的leader進行failover
- 2)Sentinel leader選取slave節(jié)點中的一個slave作為新的Master節(jié)點.對slave選舉需要對slave進行選舉的方法如下:a)?與master斷開時間
如果與master斷開的時間超過down-after-milliseconds(sentinel配置) * 10秒加上從sentinel判定master不可用到sentinel開始執(zhí)行故障轉移之間的時間,就認為該slave不適合提升為master.
b)?slave優(yōu)先級
每個slave都有優(yōu)先級,保存在redis.conf配置文件里.如果優(yōu)先級相同,則繼續(xù)進行.
c) 復制偏移位置
復制偏移紀錄著從master復制數據復制到哪里,復制偏移越大表明從master接受的數據越多,如果復制偏移量也一樣,繼續(xù)進行選舉
d)?Run ID
選舉具有最小Run ID的Slave作為新的Master
流程圖如下:

- 3) ?Sentinel leader會在上一步選舉的新master上執(zhí)行slaveof no one操作,將其提升為master節(jié)點
- 4)Sentinel leader向其它slave發(fā)送命令,讓剩余的slave成為新的master節(jié)點的slave
- 5)Sentinel leader會讓原來的master降級為slave,當恢復正常工作,Sentinel leader會發(fā)送命令讓其從新的master進行復制
以上failover操作均有sentinel自己獨自完成,完全無需人工干預.
總結
使用sentinel實現了Redis的高可用,當master出現故障時,完全無需人工干預即可實現故障轉移.避免了對業(yè)務的影響,提高了運維工作效率.
在部署sentinel的時候,建議使用奇數個sentinel節(jié)點,最少三個sentinel節(jié)點.
寫在最后
由于sentinel知識點比較多,這里僅給大家進行介紹,讓大家有個了解,想了解更多可與我聯系.謝謝.
轉載請注明本頁網址:
http://www.snjht.com/jiaocheng/1946.html