GaussDB(for Redis)揭祕：Redis存算分離架構最全解析

前言：

本文根據華爲雲NoSQL數據庫架構師餘汶龍，在今年的中國系統架構師大會SACC上的演講整理而成，內容以下。

本次分享的大綱分紅以下四個部分：

1. 什麼是GaussDB(for Redis)？
2. 爲何選擇存算分離
3. 設計與實現
4. 競爭力總結
   

什麼是GaussDB(for Redis)

1.1 開源Redis有哪些缺點？

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

1.AOF膨脹問題

開源Redis的定位是緩存，但爲了知足業務的宕機數據快速恢復，增長了AOF日誌來實現必定的持久化功能。惋惜在Redis的設計裏，並無一個轉儲文件機制來消耗AOF，而是經過AOF重寫，來不斷的去重合並舊日誌。而該重寫機制須要一次fork調用，該調用會帶來內存翻倍、性能阻塞等問題。

2.快照備份問題

隨着業務對Redis的依賴愈來愈重，數據備份也變得很是重要。衆所周知，Redis架構並不是MVCC結構，所以想要備份數據，不免須要悲觀鎖定以後，拷貝內存數據。不過Redis做者設計了一個copy on write的方案，即調用fork，建立出子進程進行數據拷貝，避免了用戶態加鎖。然而，這個過程其實會在內核側加鎖，依然會給業務性能帶來明顯抖動。

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數據庫，而不是緩存。它有兩個跟業界徹底不同的特性：

1. 存算分離。高斯Redis基於華爲內部自研分佈式存儲DFV，提供強大的數據存儲能力，包括強一致、彈性擴縮容等高級特性。DFV爲什麼物？它是華爲全棧數據服務的基石，好比文件EVS、對象OBS、塊存儲，還有數據庫族、大數據族，都依賴於此，能夠想象它的強大及穩定性。
2. 多模架構。實際上高斯Redis是多模數據庫Gauss NoSQL的一員，Gauss NoSQL提供了全棧的分佈式KV引擎、用戶態文件系統、存儲池等技術，只須要在接口上封裝Redis協議，便可輕鬆實現一個全新的NoSQL產品。相似的，咱們還提供了MongoDB、Cassandra、InfluxDB等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，在數據小於內存的點查場景下，咱們的性能也有很大優點，固然範圍查詢還待優化中。

5. 結束語

以上就是本次分享的關於高斯Redis的所有內容，更多內容請參考高斯Redis官方博客：官方博客 和高斯Redis官方首頁：官方首頁 。

點擊關注，第一時間瞭解華爲雲新鮮技術~