【數據庫】全方位解析雲數據庫Redis災備簡介！

數據是很多業務的核心元素，作爲數據載體的數據庫承擔着舉足輕重的責任。雲數據庫Redis版作爲高性能的Key-Value數據庫，在業務場景中往往承載着大量的重要數據。本文將全方位地爲您解析雲數據庫Redis版的災備機制。

雲數據庫Redis版容災架構演進

程序在運行過程中總會遇到各種各樣的問題，例如程序BUG、設備故障、機房斷電等，理想的容災機制能夠在這些問題發生時，保證數據的一致性和業務可用性。雲數據庫Redis版爲了保證業務的高可用，不斷提升容災能力，爲不同的業務場景提供相應的高可用方案。

下圖反映了雲數據庫Redis版容災架構的演進歷史。

當前三種方案同時存在，您可以根據業務需求選擇合適的方案。下文將對各方案進行詳細介紹。

單可用區高可用機制

Redis全架構均支持單機房HA高可用架構。HA監控系統採用獨立的平臺化架構，提供跨可用區的高可用機制，使雲數據庫Redis版比自建Redis更穩定。

標準版-雙副本

標準版-雙副本實例採用雙機主從（Master-Replica）架構，高可用HA模塊偵測到主節點故障時，會自動進行主從切換，將Replica提升爲Master，而原來的Master恢復連接後會成爲新的Replica。實例默認開啓數據持久化功能，支持數據自動備份，您可以使用備份文件回滾實例或者克隆實例，有效地解決誤操作問題並實現可靠的災備。

集羣版-雙副本

集羣版-雙副本實例由配置服務器、代理服務器和分片服務器組成：

配置服務器（Config Server）是用於提供全局路由信息和配置信息的集羣管理工具，採用遵循Raft協議的三副本集羣架構；
代理服務器（Proxy Server）爲單節點架構，集羣版結構中會有多個Proxy，系統自動對所有Proxy進行負載均衡及故障轉移；
分片服務器（Shard Server）同樣採用雙副本高可用架構，與標準版-雙副本實例相同，主節點故障之後，HA模塊會自動進行主從切換保證服務高可用，並更新Proxy Server和Config Server的信息。

讀寫分離版

讀寫分離版實例由代理服務器、主從架構的讀寫節點以及若干只讀副本（Read-Only Replica）構成。

高可用HA模塊實時監測各節點的狀態，在讀寫節點的主節點發生故障時發起主從切換，同時將只讀節點連接到新的主節點上來；
當只讀節點發生故障時， HA模塊將重建只讀節點，並更新相應的路由及權重信息。
Proxy實時監控只讀節點的服務狀態，當發現某個只讀節點狀態異常時會降低該節點的權重。如果只讀節點多次連接失敗，Proxy將停止該節點的服務，直至其恢復正常。

同城容災機制

Redis標準版和集羣版提供跨雙機房的同城容災架構。如果業務爲單一地域部署，且對容災要求較高，可在創建雲數據庫 Redis版實例時，選擇支持同城容災的可用區，如下圖中的華東1多可用區（B+F）或華東1多可用區（G+H）。

創建多可用區實例時，備機房將創建與主機房相同規格的Replica實例，主備機房的實例數據通過專門的複製通道同步。

當主機房出現電力或網絡問題時，Replica實例將升級爲Master實例，系統調用Config Server接口爲Proxy更新路由信息。底層網絡根據路由精細度實現故障切換，主機房網段的精細度高，因此在正常情況下，數據會直接傳輸到主機房的實例；當主機房出現故障時，不會上傳路由明細信息，此時骨幹網中只存在備機房的精細度較低的大網段路由信息，系統就會自動把請求路由到備機房，從而實現故障切換。

雲數據庫Redis版優化了Redis的同步機制，在同步位點上借鑑MySQL的GTID，實現了全局OpID，並且查找OpID的操作通過後臺線程無鎖進行。同時，發送AOF binlog是異步同步的過程，可以限流，保障了Redis服務的性能。