Redis 備份、容災及高可用實戰
《Redis 備份、容災及高可用實戰》要點：
本文介紹了Redis 備份、容災及高可用實戰，希望對您有用。如果有疑問，可以聯系我們。
Redis已經大量應用于各種互聯網架構場景中,其優異的性能,良好的操作性,以及大量的場景應用案例,使得Redis備受矚目.本文作者向大家介紹了一種Redis在非大集群分布式應用場景下的災備辦理方案.一起來品讀一下吧~
作者介紹
郝朝陽,宜搜科技,運維工程師,負責前端運維工作.專注于運維自動化的實現.致力于DevOps思想的推廣,贊助企業形成形成自有文化的運維體系建設.
一,Redis簡單介紹
Redis是一個高性能的key-value非關系型數據庫,由于其具有高性能的特性,支持高可用、持久化、多種數據結構、集群等,使其脫穎而出,成為常用的非關系型數據庫.此外,Redis的使用場景也比擬多.
會話緩存(Session Cache)
Redis緩存會話有非常好的優勢,因為Redis提供持久化,在需要長時間堅持會話的應用場景中,如購物車場景這樣的場景中能提供很好的長會話支持,能給用戶提供很好的購物體驗.
全頁緩存
在WordPress中,Pantheon提供了一個不錯的插件
wp-redis,這個插件能以最快的速度加載你曾經瀏覽過的頁面.隊列
Reids提供list和set操作,這使得Redis能作為一個很好的消息隊列平臺來使用.
我們常通過Reids的隊列功能做購買限制.比如到節假日或者推廣期間,進行一些活動,對用戶購買行為進行限制,限制本日只能購買幾次商品或者一段時間內只能購買一次.也比較適合適用.
排名
Redis在內存中對數字進行遞增或遞減的操作實現得非常好.所以我們在很多排名的場景中會應用Redis來進行,比如小說網站對小說進行排名,根據排名,將排名靠前的小說保舉給用戶.
發布/訂閱
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主從復制優點與不敷
優點
實現了對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進程合作,當多個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知識點比擬多,這里僅給大家進行介紹,讓大家有個了解,想了解更多可與我聯系.謝謝.
END
近期好文：
第八屆全球運維大會
即 GOPS2017·上海站將于2017年11月17日-18日在上海舉行
各種出色等您發掘.
點擊閱讀原文存眷活動官網
《Redis 備份、容災及高可用實戰》是否對您有啟發，歡迎查看更多與《Redis 備份、容災及高可用實戰》相關教程，學精學透。維易PHP學院為您提供精彩教程。
轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/9220.html
