夏周：阿里雲 Redis 容災體系介紹

摘要： 2018資料庫直播大講堂峰會Redis專場，來自阿里雲技術專家夏周為大家介紹了阿里雲Redis容災體系。本文主要分單機房主備容災、同城雙機房容災和異地多機房容災&多活三部分進行講解，其中包括它們的產品定位、架構介紹以及同步優化和內核優化等。

原文

2018資料庫直播大講堂峰會Redis專場，來自阿里雲技術專家夏周為大家介紹了阿里雲Redis容災體系。本文主要分單機房主備容災、同城雙機房容災和異地多機房容災&多活三部分進行講解，其中包括它們的產品定位、架構介紹以及同步優化和內核優化等。

直播視頻：https://yq.aliyun.com/video/play/1312

PDF下載：https://yq.aliyun.com/download/2447

以下為精彩視頻內容整理：

單機房主備容災

阿里雲Redis雙副本容災形態

阿里雲Redis推出了4.0版本，架構上有集群版、標準版和讀寫分離版。標準版是主備版本，提供最好的Redis命令兼容性，當主節點出現宕機時，HA高可用切換模塊會去做故障遷移，將Slave提升為Master，原來的Master恢復後作為新的Slave；集群版架構相對複雜，後端有多個DB節點，每個DB節點架構類似於標準版主備形態，多個DB節點數據需要做路由，就需要多個Proxy節點，集群版還增加一個Configserver，該角色保存了集群間元素信息。當某一個DB節點出現宕機，都會有一個獨立的切換模塊，並更新Configserver和Proxy的信息；讀寫分離版只有一個DB節點，一個Master上掛了多個只讀節點，當讀流量進來時，會根據Proxy判斷後端只讀節點數量做自動負載均衡，當Master出現宕機時，只讀節點需要掛載到新的Master上。

高可用(HA)架構

HA本質上是在做Master故障時、Slave自動提升為主，解決關鍵問題是判斷是否要做切換。HA本身多機房部署，保證自身是高可用的，每個機房會有多個HA模塊，每個HA模塊負責一部分節點HA切換，當某一個工作HA節點宕機後，另外一些HA節點會做爭搶式調度。我們優先同機房HA節點做探測，對於後端Redis的探活邏輯也是有很多種策略的，比如從DNS VIP層面探測後端服務的可用性，也會探測本身DB節點是否存活，以及主機、磁碟是否完好。

獨立HA線程優化

阿里雲Redis在運營過程中進行了優化，Redis本身是單線程的，當做keys、hgetall等時，Redis很容易出現假死情況，HA可能會誤切換。主線程仍然可以做任何操作，我們的優化是專門啟動了一個狀態線程監測主線程是否存活，也會響應HA模塊的探活請求，並探測磁碟可用性。另外，狀態線程也會吐出狀態信息，保證監控採集不會因為主線程hang住而採集不到信息。

同城雙機房容災

同城雙機房容災的產品定位是：對於業務單元化部署或本身就是單一地域的業務，對容災有需求，主機房故障時，流量能迅速切換到備機房，主機房恢復時，流量可以切回。

目前Redis同城容災架構如圖。下半部分是Redis本身的架構情況，上半部分是底層傳輸網路情況。購買Redis後，我們可以取得域名和埠，經過DNS解析走到骨幹網，流量再通過LVS集群流到Proxy，最後到後端Master節點。當主機房出現掉電或網路不通時，Redis會有一鍵切換程序，備機房Slave提升為Master，並調用Configserver介面為Proxy推新的路由信息，也會更新MetaDB的一些信息；底層網路走大小段路由方式，優先選擇更為細緻的路由，當主機房出現故障時，就不會向主機房上傳路由明細信息，骨幹網只有備機房大段路由信息，這時就會自動把請求路由到備機房。

同步優化——Log Based Replication

當主機房出現故障時流量切換到備機房，當主機房恢復時都會從備機房做同步。Redis最早提供全量同步機制，整機房全量同步會帶來災難性後果，如果所有的Slave都做全量同步，子進程CPU會跑滿，還要瘋狂的向恢復的主機房傳輸的RDB寫流量，由於流量太大可能導致備機房服務不可用。

我們目前提供的同步機制對Redis持久化機製做了改造，會有slipshot對應日誌位點，AOFbinlog不斷做最佳寫，當AOFbinlog堆積到一定程度，需要重新做slipshot對其進行清理。AOFbinlog每一個操作寫命令會增加一些元數據信息Opid，我們給每一個操作增加一個全局唯一的ID，當Slave出現同步中斷時，會通知Master同步Opid位點信息，此時位點已經不是offset信息，Master會判斷此Opid是否在AOFbinlog中保存，如果在即非同步發送AOFbinlog給Slave，Slave不斷從Master本地磁碟讀缺失增量，當追上Master同步時，再去內存中把一部分增量拿過來。

總結來看，同步位點借鑒了MySQL GTID，實現全局Opid；性能保證上，查找Opid位點信息是後台線程操作，做到無鎖，發送AOFbinlog是非同步同步，可以去做限流；同時，我們做到向前、向後兼容，可以做平滑升級、回滾。

Slave和Master的具體通信情況如圖，當Slave和Master出現同步中斷時，Slave給Master發送PSYNC、runnid、offset和Opid信息，Master根據offset判斷backlog是否能滿足需求，如果可以滿足需求，直接從backlog複製數據發給Slave即可，如果不能滿足需求，就會通知Slave開始AOF Psync，Master首先會通過Opid找AOFbinlog中同步位點，然後無鎖通知主線程，主線程非同步發送AOFbinlog，當Slave追上AOFbinlog後，Master還要同步aof_buf&repl_offset 給Slave。

異地多機房容災&多活

異地多機房容災&多活的產品定位是：業務對可用性要求極高，如金融類、部分民生類業務等；允許N-1機房斷電，任一機房均能承擔所有流量。

異地多活架構如圖，上海中心和深圳中心都會有兩個Redis集群，可以做到互相同步。底層鏈路有BLS Manager，上海中心生產一些增量數據，通過Collector寫入BLS Tunnel，深圳中心Receiver會從BLS Tunnel中消費增量數據，並寫入深圳Master集群，這樣，上海中心數據就同步到深圳中心了。同理，深圳中心數據同步到上海中心也是如此。BLS Manager會去做一些調度，比如Collector和Receiver掛掉時，BLS Manager負責拉起或創建新的Collector和Receiver，BLS Manager也會對BLS Tunnel做管理。

內核優化

增量生產

獲取增量介面是內核以命令方式原生支持的，是一個標準化get介面，支持現有開源SDK，支持增量過濾，包括庫級過濾和key模式匹配過濾。Collector消費增量時，會發送opget opid信息，明確從哪一點開始獲取oplog，Redis主線程會創建任務通知後台線程，後台線程基於Opid查找增量位點，無鎖通知主線程可以從哪開始讀，Redis非同步讀取AOFbinlog並做解析和封裝操作，同時緩存客戶端狀態，然後回復Collector，Collector下次發送opget opid命令時，就不再需要走上述流程了。

增量消費

增量格式本身兼容Redis協議，目的端接收並且執行就可以了。其中，timestamp做時間點恢復。增量消費要避免兩個問題：一是複製回源，不能讓A複製給B的再從B複製回A，我們會標識標識oplog來源實例（server_id)，如果複製回源，直接丟棄即可；一是環形複製，如何避免C通過B複製的數據再次返回A，我們記錄了每一個src_server_id，以及src_server_id在C上max_opid情況，通過判斷是否發生環形複製。

更多技術乾貨敬請關注云棲社區知乎機構號：阿里云云棲社區 - 知乎