Redis中怎么實現(xiàn)備份和容災

Redis中怎么實現(xiàn)備份和容災，相信很多沒有經(jīng)驗的人對此束手無策，為此本文總結了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個問題。

1. 會話緩存（Session Cache）

Redis緩存會話有非常好的優(yōu)勢，因為Redis提供持久化，在需要長時間保持會話的應用場景中，如購物車場景這樣的場景中能提供很好的長會話支持，能給用戶提供很好的購物體驗。

2. 全頁緩存

在WordPress中，Pantheon提供了一個不錯的插件wp-redis，這個插件能以最快的速度加載你曾經(jīng)瀏覽過的頁面。

3. 隊列

Reids提供list和set操作，這使得Redis能作為一個很好的消息隊列平臺來使用。

我們常通過Reids的隊列功能做購買限制。比如到節(jié)假日或者推廣期間，進行一些活動，對用戶購買行為進行限制，限制今天只能購買幾次商品或者一段時間內只能購買一次。也比較適合適用。

4. 排名

Redis在內存中對數(shù)字進行遞增或遞減的操作實現(xiàn)得非常好。所以我們在很多排名的場景中會應用Redis來進行，比如小說網(wǎng)站對小說進行排名，根據(jù)排名，將排名靠前的小說推薦給用戶。

5. 發(fā)布/訂閱

Redis提供發(fā)布和訂閱功能，發(fā)布和訂閱的場景很多，比如我們可以基于發(fā)布和訂閱的腳本觸發(fā)器，實現(xiàn)用Redis的發(fā)布和訂閱功能建立起來的聊天系統(tǒng)。

此外還有很多其它場景，Redis都表現(xiàn)的不錯。

二，Redis使用中單點故障問題

正是由于Redis具備多種優(yōu)良特新，且應用場景非常豐富，以至于Redis在各個公司都有它存在的身影。那么隨之而來的問題和風險也就來了。Redis雖然應用場景豐富，但部分公司在實踐Redis應用的時候還是相對保守使用單節(jié)點部署，那為日后的維護帶來了安全風險。

在2015年的時候，曾處理過一個因為單點故障原因導致的業(yè)務中斷問題。當時的Redis都未采用分布式部署，采用單實例部署，并未考慮容災方面的問題。

當時我們通過Redis服務器做用戶購買優(yōu)惠商品的行為控制，但后來由于未知原因Redis節(jié)點的服務器宕機了，導致我們無法對用戶購買行為進行控制，造成了用戶能夠在一段時間內多次購買優(yōu)惠商品的行為。

這種宕機事故可以說已經(jīng)對公司造成了不可挽回的損失了，安全風險問題非常嚴重，作為當時運維這個系統(tǒng)的我來說有必要對這個問題進行修復和在架構上的改進。于是我開始了解決非分布式應用下Redis單點故障方面的研究學習。

三，非分布式場景下Redis應用的備份與容災

Redis主從復制現(xiàn)在應該是很普遍了。常用的主從復制架構有如下兩種架構方案。

常用Redis主從復制

• 方案一

這是最常見的一種架構，一個Master節(jié)點，兩個Slave節(jié)點?？蛻舳藢憯?shù)據(jù)的時候是寫Master節(jié)點，讀的時候，是讀取兩個Slave，這樣實現(xiàn)讀的擴展，減輕了Master節(jié)點讀負載。

• 方案二

這種架構同樣是一個Master和兩個Slave。不同的是Master和Slave1使用keepalived進行VIP轉移。Client連接Master的時候是通過VIP進行連接的。避免了方案一IP更改的情況。

Redis主從復制優(yōu)點與不足

• 優(yōu)點

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術社區(qū)

2. 實現(xiàn)了對master數(shù)據(jù)的備份，一旦master出現(xiàn)故障，slave節(jié)點可以提升為新的master，頂替舊的master繼續(xù)提供服務

3. 實現(xiàn)讀擴展。使用主從復制架構， 一般都是為了實現(xiàn)讀擴展。Master主要實現(xiàn)寫功能，  Slave實現(xiàn)讀的功能

• 不足

架構方案一

當Master出現(xiàn)故障時，Client就與Master端斷開連接，無法實現(xiàn)寫功能，同時Slave也無法從Master進行復制。

此時需要經(jīng)過如下操作(假設提升Slave1為Master):

1)在Slave1上執(zhí)slaveof no one命令提升Slave1為新的Master節(jié)點。

2)在Slave1上配置為可寫，這是因為大多數(shù)情況下，都將slave配置只讀。

3)告訴Client端(也就是連接Redis的程序)新的Master節(jié)點的連接地址。

4)配置Slave2從新的Master進行數(shù)據(jù)復制。

架構方案二

當master出現(xiàn)故障后，Client可以連接到Slave1上進行數(shù)據(jù)操作，但是Slave1就成了一個單點，就出現(xiàn)了經(jīng)常要避免的單點故障(single point of failure)。

之后需要經(jīng)過如下操作：

1）在Slave1上執(zhí)行slaveof no one命令提升Slave1為新的Master節(jié)點

2）在Slave1上配置為可寫，這是因為大多數(shù)情況下，都將Slave配置只讀

3）配置Slave2從新的Master進行數(shù)據(jù)復制

可以發(fā)現(xiàn)，無論是哪種架構方案都需要人工干預來進行故障轉移(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實例出現(xiàn)了故障

• 自動故障轉移

如果master不像預想中那樣正常運行，Sentinel可以啟動故障轉移過程，其中的一個slave會提成為master，其它slave會重新配置來使用新的master，使用Redis服務的應用程序，當連接時，也會被通知使用新的地址。

• 配置提供者

Sentinel可以做為客戶端服務發(fā)現(xiàn)的認證源：客戶端連接Sentinel來獲取目前負責給定服務的Redis master地址。如果發(fā)生故障轉移，Sentinel會報告新的地址。

六，Redis Sentinel架構

七，Redis Sentinel實現(xiàn)原理

Sentinel集群對自身和Redis主從復制進行監(jiān)控。當發(fā)現(xiàn)Master節(jié)點出現(xiàn)故障時，會經(jīng)過如下步驟：

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復制數(shù)據(jù)復制到哪里，復制偏移越大表明從master接受的數(shù)據(jù)越多，如果復制偏移量也一樣，繼續(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進行復制

看完上述內容，你們掌握Redis中怎么實現(xiàn)備份和容災的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業(yè)資訊頻道，感謝各位的閱讀！