Redis 備份、災難復原及高可用實戰的範例分析

 一、Redis簡單介紹

Redis是一個高效能的key-value非關聯式資料庫，由於其具有高效能的特性，支援高可用、持久化、多種資料結構、叢集等，使其脫穎而出，成為常用的非關聯式資料庫。

此外，Redis的使用場景也比較多。

會話快取(Session Cache)

Redis快取會話有非常好的優勢，因為Redis提供持久化，在需要長時間維持會話的應用程式場景中，如購物車場景這樣的場景中能提供很好的長會話支持，能為使用者提供很好的購物體驗。

全頁快取

在WordPress中，Pantheon提供了一個不錯的外掛wp-redis，這個外掛程式能以最快的速度載入你曾經瀏覽過的頁面。

佇列

Redis支援list和set操作，因此它很適合用作訊息佇列平台。我們常透過Reids的佇列功能做購買限制。例如到假日或推廣期間，進行一些活動，對用戶購買行為進行限制，限制今天只能購買幾次商品或一段時間內只能購買一次。也比較適合適用。

排名

Redis在記憶體中對數字進行遞增或遞減的操作實現得非常好。所以我們在很多排名的場景中會應用Redis來進行，例如小說網站對小說進行排名，根據排名，將排名前幾名的小說推薦給用戶。

發布/訂閱

Redis提供發布和訂閱功能，發布和訂閱的場景很多，例如我們可以基於發布和訂閱的腳本觸發器，實現用Redis的發布和訂閱功能建立起來的聊天系統。

此外還有很多其它場景，Redis都表現的不錯。

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

Redis在各個公司都得以應用，其多種優良特性和豐富的應用場景是其存在的原因。那麼隨之而來的問題和風險就來了。 Redis雖然應用場景豐富，但部分公司在實踐Redis應用程式的時候還是相對保守使用單節點部署，那為日後的維護帶來了安全風險。

我曾在2015年處理過一起因單點故障導致的業務中斷問題。當Redis最初被部署時，它使用的是單節點部署而不是分散式部署，並且沒有考慮容災方面的問題。

當時我們透過Redis伺服器做用戶購買優惠商品的行為控制，但後來由於未知原因Redis節點的伺服器宕機了，導致我們無法對用戶購買行為進行控制，造成了用戶能夠在一段時間內多次購買優惠商品的行為。

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

三、非分散式場景下Redis應用程式的備份與容災

Redis主從複製現在應該是很普遍了。常用的主從複製架構有下列兩種架構方案。

常用Redis主從複製

方案一

一般情況下，這種結構最為常見，即一個主節點和兩個從節點。客戶端寫資料的時候是寫Master節點，讀的時候，是讀取兩個Slave，這樣實現讀的擴展，減輕了Master節點讀負載。

方案二

這種架構同樣是一個Master和兩個Slave。 Master和Slave1使用keepalived來實現VIP遷移的方式有所不同。 Client連線Master的時候是透過VIP進行連線的。避免了方案一IP更改的情況。

Redis主從複製優點與不足

優點

實現了對master資料的備份，一旦master出現故障，slave節點可以提升為新的master，頂替舊的master繼續提供服務

實作讀取擴充。使用主從複製架構， 一般都是為了實現讀取擴充。 Master主要實作寫入功能， Slave實作讀取的功能

不足

#架構方案一

當Master故障時，Client就與Master端斷開連接，無法實現寫入功能，同時Slave也無法從Master進行複製。

此時需要經過以下操作(假設提升Slave1為Master):

1. 在Slave1上執slaveof no one指令提升Slave1為新的Master節點。

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

3. 告訴Client端(也就是連接Redis的程式)新的Master節點的連接位址。

4. 配置Slave2從新的Master進行資料複製。

架構方案二

當master故障後，Client可以連接到Slave1上進行資料操作，但是Slave1就變成一個單點，就出現了經常要避免的單點故障(single  point of failure)。

之後需要經過以下操作：

1. #在Slave1上執行slaveof no one指令提升Slave1為新的Master節點

2. 在Slave1上配置為可寫，這是因為大多數情況下，都會將Slave配置只讀

3. 配置Slave2從新的Master進行資料複製

要注意的是，所有架構方案都需要手動介入才能進行故障轉移(failover)。需要人工幹預就增加了維運工作量，同時也對業務造成了巨大影響。這時候可以使用Redis的高可用方案-Sentinel

##四、Redis Sentinel介紹

Redis Sentinel為Redis提供了高可用方案。從實務方面來說，使用Redis  Sentinel可以創造一個無需人為幹預就可以預防某些故障的Redis環境。

Redis Sentinel採用分散式架構，執行多個程序進行協同合作。執行多個Sentinel進程合作，當多個Sentinel同一給定的master無法再繼續提供服務，就會執行故障偵測，這會降低誤報的可能性。

五、Redis Sentinel功能

Redis Sentinel在Redis高可用方案中主要作用有下列功能：

監控

##Sentinel會不斷的檢查master和slave是否像預期那樣正常運行

#通知

透過API，Sentinel能夠通知系統管理員、程式監控的Redis實例出現了故障

自動故障轉移

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

設定提供者

Sentinel可以做為客戶端服務發現的認證來源：客戶端連結Sentinel來取得目前負責給定服務的Redis  master位址。如果發生故障轉移，Sentinel會報告新的位址。

• 六、Redis Sentinel架構

#2、Redis Sentinel實作原理

################################ Sentinel叢集對自身和Redis主從複製進行監控。當發現Master節點故障時，會經過以下步驟：############1)Sentinel之間進行選舉，選出一個leader，由選出的leader進行failover##### #######Sentinel領導人從Slave節點中選擇一個作為新的主節點。下面是對該句話的重寫： 要實施對slave的選舉，需要執行以下選舉方法：a) 與master斷開連接的時間############如果與master斷開的時間超過down-after-milliseconds(sentinel配置) *  10秒加上從sentinel判定master不可用到sentinel開始執行故障轉移之間的時間，就認為該slave不適合提升為master。 ######b) slave優先權######每個slave都有優先權，儲存在redis.conf設定檔裡。如果優先順序相同，則繼續進行。 ######c) 複製偏移位置######複製偏移記錄著從master複製資料複製到哪裡，複製偏移越大表示從master接受的資料越多，如果複製偏移量也是一樣，繼續進行選舉######d) Run ID######選舉具有最小Run ID的Slave作為新的Master######流程圖如下：###### #######################3) Sentinel leader會在上一步驟選舉的新master上執行slaveof no one操作，將其提升為master節點## ##########4)Sentinel leader向其它slave發送指令，讓剩餘的slave成為新的master節點的slave###########5)Sentinel leader會讓原來的master降級為slave，當恢復正常工作，Sentinel  leader會發送指令讓其從新的master進行複製############以上failover操作均有sentinel自己獨自完成，完全無需人工幹預。 ###

以上是Redis 備份、災難復原及高可用實戰的範例分析的詳細內容。更多資訊請關注PHP中文網其他相關文章！