華為云企業級Redis揭秘第12期：2021最新架構分享

【最新活動】企業級Redis專場熱銷中！首月免費，包年僅需4折！

前言：本文根據華為云NoSQL數據庫架構師余汶龍，在今年的中國系統架構師大會SACC上的演講整理而成，內容如下。

本次分享的大綱分成如下四個部分：

什么是GaussDB(for Redis)？

為什么選擇存算分離

設計與實現

競爭力總結

1.? 什么是GaussDB(for Redis)

1.1 開源Redis有哪些缺點？

要回答什么是GaussDB(for Redis)（下文簡稱高斯Redis）的問題，首先要從背景講起。開源Redis是個非常好的KV緩存，但隨著各種業務的蓬勃發展，數據規模、吞吐規模、業務復雜度的不斷上升，開源Redis暴露出諸多問題：

1. AOF膨脹問題

開源Redis的定位是緩存，但為了滿足業務的宕機數據快速恢復，增加了AOF日志來實現一定的持久化功能?？上г赗edis的設計里，并沒有一個轉儲文件機制來消耗AOF，而是通過AOF重寫，來不斷的去重合并舊日志。而該重寫機制需要一次fork調用，該調用會帶來內存翻倍、性能阻塞等問題。

2. 快照備份問題

3. 主從脫節問題

開源Redis采用主從高可用架構，數據采用異步模式傳輸。因此主宕機之后，很容易造成數據丟失或不一致。此外，當主節點寫入壓力較大時，單線程的主從復制很可能無法追平增量數據，就會導致buffer堆積，進一步還可能出現寫失敗甚至OOM的災難。雖然Redis能夠通過臨時生成快照并同步大文件，來嘗試追平主從巨大差異，但如前文所述，此時又會引發fork系列問題。

4. fork問題

fork其實是個非常重的系統調用，雖然是寫時拷貝，但是通常也會給他預留一倍的內存。fork工作時還需要加鎖拷貝進程頁表等信息，對業務的影響非常之大。上述3個問題的背后都有fork的因素，通常需要DBA采用關閉主節點AOF、關閉主節點備份等復雜運維手段來避免。但在主從頻繁切換、節點數很多的場景下，運維是非常困難的。甚至在主從脫節場景，理論上毫無辦法規避。

5. 容量問題

開源Redis不適合大規模使用，有兩個重要因素限制了其擴展性。首先是fork限制了Redis的垂直擴展能力（Scale Up），數據量越大，fork越慢，對業務的影響就越大，因此單個redis進程可承載的數據量非常有限。其次，低效率的gossip集群管理限制了其水平擴展能力（Scale Out）：因為節點數越多，其故障發現的時間越長，并且內部通信的網絡風暴成幾何級數增加，導致大集群幾乎不可用。

1.2 業界有哪些解決辦法？

以上就是各大企業在開源Redis的生產實踐中，真實碰到的經典問題。這些問題限制了開源Redis的大規模應用。因此，近年來業界提出了非常多的解決方案，見下圖。

本質上，Redis是一種KV存儲，按照場景其實可以進一步劃分為兩大陣營：緩存與持久化。

緩存場景：一般用來存放秒殺、熱點事件的數據。比如微博熱搜，這類數據是有有效期的，而且可丟。

持久化場景：在用Redis做緩存的時候，由于其接口簡單、功能豐富，大家必然希望將更多重要數據也持久化存放到Redis，比如歷史訂單、特征工程、位置坐標、機器學習等。這類數據的數據量往往很大、有效期也很長、一般不可丟。

緩存場景比較簡單就是開源Redis，持久化場景業界已有非常多自研產品，比如360的ssdb/pika，阿里的tair，騰訊的tendis，當然華為云的高斯Redis也屬于自研的持久化Redis。

這里也補充另一個做持久化的理由，從成本考慮，256G內存條價格比256G的SSD磁盤高了將近30倍，在可用容量上也有巨大差異。

1.3 華為云數據庫的解法是啥？

華為云數據庫團隊吸取開源Redis的經驗，選擇了自研持久化Redis，即今天分享的主角——高斯Redis。它的一句話定位是：支持Redis協議的NoSQL數據庫，而不是緩存。它有兩個跟業界完全不一樣的特性：

存算分離。高斯Redis基于華為內部自研分布式存儲DFV，提供強大的數據存儲能力，包括強一致、彈性擴縮容等高級特性。DFV為何物？它是華為全棧數據服務的基石，比如文件EVS、對象OBS、塊存儲，還有數據庫族、大數據族，都依賴于此，可以想象它的強大及穩定性。

多模架構。實際上高斯Redis是多模數據庫Gauss NoSQL的一員，Gauss NoSQL提供了全棧的分布式KV引擎、用戶態文件系統、存儲池等技術，只需要在接口上封裝Redis協議，即可輕松實現一個全新的NoSQL產品。類似的，我們還提供了MongoDB、Cassandra、Influx等NoSQL引擎。

2. 為什么選擇存算分離？

在云原生概念鋪天蓋地的今天，數據庫也逐步走向云原生，而它的云原生有一個重要特點就是存算分離。存算分離也代表了數據庫上云的最新趨勢。

第一代數據庫服務：通過下圖可以看到，傳統IDC建設時，數據庫架設在裸金屬之上，由于數據庫服務的敏感特殊性，DBA或者研發需要關心機型的選擇、磁盤Raid陣列、組網，甚至采購等諸多事項。

第二代數據庫服務：隨著虛擬化技術的普及，應用型業務大量上云，數據庫也開始上云搬遷，最簡單的辦法是在虛擬機或容器中運行一個數據庫服務即可。這樣做的優點很明顯，但缺點有兩個：一個是通用云盤都是3副本，加上數據庫上層的多副本，資源浪費嚴重；另一個是備機資源浪費，平時無法提供服務。除此以外還有云盤IO性能等問題存在。

第三代數據庫服務：基于存算分離架構，將數據庫服務分成CPU密集的計算層和IO密集的存儲層。數據的副本管理完全交給存儲層，計算層實現無狀態轉發，既能發揮云的彈性優勢，又能全負荷分擔。不過缺點也很明顯，即基于舊架構改造難度大。

采用存算分離架構之后，數據庫服務就是個分而治之的思想：計算層負責服務化、產品化的各種處理，全程無狀態；而存儲層，就專注于數據本身的維護，包括副本、容災、硬件感知、擴縮容等等。

3. 設計與實現

接下來講整體設計與實現，首先是軟件架構。高斯Redis計算層的模塊如下，主要有cfgsvr、proxy、datanode。連接計算與存儲資源的有RocksDB和GeminiFS（自研用戶態文件系統），分別負責將kv數據轉成sst文件和負責將sst文件下推到DFV的對象存儲池中。

接下來是組網設計。一個租戶申請的數據庫資源，被我們以反親和的方式，分布在不同的物理機容器上，都屬于同一個租戶的相同VPC下。不同用戶的數據庫資源雖然也有可能共享同一臺物理機，但是由于VPC隔離，保證了數據隔離。另外，計算層的數據庫資源是獨占容器的，而存儲層資源是共享物理硬件的。

接下來解讀容災架構。既然高斯Redis定位是數據庫而不是緩存，那它對待數據的態度是嚴肅的：既實現了region內的3AZ容災，也提供了跨Region的容災。

Region內的容災，實現了一個容忍AZ級故障的高可用方案。在此故障下，數據依然保持強一致狀態，這對企業級應用提供了非常強大的數據安全保障。這套架構的可靠性指標可以滿足RPO為0，RTO小于10s的標準。

具體的實現原理是，依賴DFV的3副本強一致復制能力，計算層也做3AZ的反親和部署。當用戶的一條數據通過proxy寫到datanode1上，datanode1通過GeminiFS的用戶態文件系統，調用DFV的SDK找到一個local az的DFV存儲節點，和一個距離最近remote az的DFV存儲節點，組成多數派，寫成功后即返回給用戶。這樣的架構下，不管是計算還是存儲的AZ級故障，都對數據的安全性沒有任何影響。

接下來繼續講跨Region級別的容災。高斯Redis除了提供上述3AZ的強一致方案以外，還提供跨Region級別的容災，也就是兩個實例間的異步容災。這套方案里，我們增加了一個Rsync-Server的模塊，用來訂閱主實例上新增的日志，再把日志反解編碼成相應的格式，轉發給對端的備實例，由備實例回放即可。這套方案，可以實現雙向同步、斷點續傳、沖突解決等等。其中沖突解決，針對不同的Redis數據結構，采用不同的解決算法，保障最終一致性。

4. 競爭力總結

最后一節是對高斯Redis的優勢總結，主要包括：強一致、高可用、冷熱分離、彈性伸縮、高性能。

首先是強一致特性。

這一點主要受益于DFV的3副本機制，因此寫入高斯Redis的數據，在客戶端收到回復時，數據就已是3副本強一致的。強一致能力對業務實現非常友好，不需要忍受數據的不一致、不需要校驗數據。而開源Redis數據采用異步復制，因此主從之間總是有個差異buffer，如果掉電，這部分數據就會丟失，且在大壓力寫的時候，還會產生buffer堆積，嚴重的時候，會導致OOM。因此，高斯Redis的強一致是個非常重要的特點，能為業務提供前后一致的狀態，不用擔心開源Redis主從切換后的數據一致性問題和丟失問題。

第二個特性是高可用。

高可用是數據庫的基本能力，這里之所以要再次強調，是因為高斯Redis的可用性跟其他數據庫不同，它做到了可接受N-1個節點故障。實現原理受益于共享存儲DFV：當某一個計算節點發生故障掛掉，其維護的slot路由信息，會被剩下的節點自動接管。由于不涉及底層數據的遷移，這個接管過程非?？臁Ｒ源祟愅?，可以接受N-1個節點故障，且不影響全部數據的讀寫。當然，計算節點減少會對性能造成一定影響。

第三個特性是冷熱分離。

開源Redis的一個經典使用場景是配合MySQL做冷熱分離，但這需要業務實現代碼負責實現冷熱數據交換，并維護其一致性，這個交付邏輯比較復雜。而高斯Redis實現了它自己的冷熱分離，即用戶剛寫入的和經常訪問的數據，都被當做熱數據加載到內存中，而非頻繁訪問的數據則會被淘汰到持久化存儲中。因此使用了高斯Redis的業務，不再需要從業務層寫代碼維護冷熱交換邏輯，并且可以得到更好的一致性。

第四個特性是彈性伸縮。

采用存算分離之后的高斯Redis，可以做到按需擴容，即計算不夠擴計算，存儲不夠擴存儲即可。計算資源的擴容也很簡單，前面已經提到，這個過程其實不涉及數據的拷貝搬遷，只涉及到元數據的修改，即把相應的slot路由信息（不超過1MB）遷移到新增的節點上即可完成，因此速度是非?？斓?，秒級完成。而存儲資源的擴容更簡單，由于底層采用共享存儲，大多數情況進行邏輯擴容，這只需要用戶在控制臺上修改配額即可完成，不涉及到任何數據的搬遷和拷貝。當然也有碰到物理擴容的情形，這種情形一般是我們運維提前發現警戒水位，在這之前做平滑的遷移擴容，該過程對用戶透明無感知的。

第五個特性是高性能。

存算分離的架構看似比較重，鏈路比較復雜，實則在硬件采用、軟件優化上，可以做的更大膽更激進，比如RDMA網絡、用戶態協議、持久化內存等等。因此受益于這些專屬的存儲設備，加上我們的計算層全負荷分擔架構（不引入從節點，因此性能輕松翻倍），在對比友商的數據量大于內存的存儲場景下，我們的性能表現很好。另外，對比開源Redis，在數據小于內存的點查場景下，我們的性能也有很大優勢，當然范圍查詢還待優化中。

杭州/西安/深圳簡歷投遞：yuwenlong4@huawei.com

GaussDB(for Redis)產品主頁：

https://www.huaweicloud.com/product/gaussdbforredis.html

更多技術文章，關注GaussDB(for Redis)官方博客：

https://bbs.huaweicloud.com/community/usersnew/id_1614151726110813

MySQL Redis 云數據庫 GaussDB(for Redis) 數據庫 緩存

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。