Redis 備份、容災及高可用實戰

Redis已經大量應用於各類互聯網架構場景中，其優異的性能，良好的操做性，以及大量的場景應用案例，使得Redis備受矚目。本文做者向你們介紹了一種Redis在非大集羣分佈式應用場景下的災備解決方案。一塊兒來品讀一下吧~

一，Redis簡單介紹

Redis是一個高性能的key-value非關係型數據庫，因爲其具備高性能的特性，支持高可用、持久化、多種數據結構、集羣等，使其脫穎而出，成爲經常使用的非關係型數據庫。
此外，Redis的使用場景也比較多。

1. 會話緩存（Session Cache）
   Redis緩存會話有很是好的優點，由於Redis提供持久化，在須要長時間保持會話的應用場景中，如購物車場景這樣的場景中能提供很好的長會話支持，能給用戶提供很好的購物體驗。
2. 全頁緩存
   在WordPress中，Pantheon提供了一個不錯的插件wp-redis，這個插件能以最快的速度加載你曾經瀏覽過的頁面。
3. 隊列
   Reids提供list和set操做，這使得Redis能做爲一個很好的消息隊列平臺來使用。

   咱們常經過Reids的隊列功能作購買限制。好比到節假日或者推廣期間，進行一些活動，對用戶購買行爲進行限制，限制今天只能購買幾回商品或者一段時間內只能購買一次。也比較適合適用。

4. 排名
   Redis在內存中對數字進行遞增或遞減的操做實現得很是好。因此咱們在不少排名的場景中會應用Redis來進行，好比小說網站對小說進行排名，根據排名，將排名靠前的小說推薦給用戶。
5. 發佈/訂閱
   Redis提供發佈和訂閱功能，發佈和訂閱的場景不少，好比咱們能夠基於發佈和訂閱的腳本觸發器，實現用Redis的發佈和訂閱功能創建起來的聊天系統。

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

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

正是因爲Redis具有多種優良特新，且應用場景很是豐富，以致於Redis在各個公司都有它存在的身影。那麼隨之而來的問題和風險也就來了。Redis雖然應用場景豐富，但部分公司在實踐Redis應用的時候仍是相對保守使用單節點部署，那爲往後的維護帶來了安全風險。

在2015年的時候，曾處理過一個由於單點故障緣由致使的業務中斷問題。當時的Redis都未採用分佈式部署，採用單實例部署，並未考慮容災方面的問題。

當時咱們經過Redis服務器作用戶購買優惠商品的行爲控制，但後來因爲未知緣由Redis節點的服務器宕機了，致使咱們沒法對用戶購買行爲進行控制，形成了用戶可以在一段時間內屢次購買優惠商品的行爲。

這種宕機事故能夠說已經對公司形成了不可挽回的損失了，安全風險問題很是嚴重，做爲當時運維這個系統的我來講有必要對這個問題進行修復和在架構上的改進。因而我開始瞭解決非分佈式應用下Redis單點故障方面的研究學習。

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

Redis主從複製如今應該是很廣泛了。經常使用的主從複製架構有以下兩種架構方案。

經常使用Redis主從複製

• 方案一
  
  這是最多見的一種架構，一個Master節點，兩個Slave節點。客戶端寫數據的時候是寫Master節點，讀的時候，是讀取兩個Slave，這樣實現讀的擴展，減輕了Master節點讀負載。
• 方案二
  
  這種架構一樣是一個Master和兩個Slave。不一樣的是Master和Slave1使用keepalived進行VIP轉移。Client鏈接Master的時候是經過VIP進行鏈接的。避免了方案一IP更改的狀況。

Redis主從複製優勢與不足

• 優勢

1. 實現了對master數據的備份，一旦master出現故障，slave節點能夠提高爲新的master，頂替舊的master繼續提供服務
2. 實現讀擴展。使用主從複製架構， 通常都是爲了實現讀擴展。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進程合做，當多個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架構

七，Redis Sentinel實現原理

Sentinel集羣對自身和Redis主從複製進行監控。當發現Master節點出現故障時，會通過以下步驟：

• 1）Sentinel之間進行選舉，選舉出一個leader，由選舉出的leader進行failover

• 2）Sentinel leader選取slave節點中的一個slave做爲新的Master節點。對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本身獨自完成，徹底無需人工干預。

總結

使用sentinel實現了Redis的高可用，當master出現故障時，徹底無需人工干預便可實現故障轉移。避免了對業務的影響，提升了運維工做效率。
在部署sentinel的時候，建議使用奇數個sentinel節點，最少三個sentinel節點。

寫在最後

因爲sentinel知識點比較多，這裏僅給你們進行介紹，讓你們有個瞭解。

原文：https://www.sohu.com/a/167105...