技術背景

目前，KV 存儲的廣泛使用極大程度上源于快速訪問的業務需求，而這種業務通常對時延敏感度高，在較好的平均性能下，還需要解決特定場景下的性能抖動。開源 Redis 在 AOF 重寫、RDB、主從同步等操作時，為不影響主線程，采用 fork 創建子線程去執行，但由于主線程仍在提供服務，觸發 Copy-On-Write 時會引起性能抖動，導致長尾時延。

華為云 GeminiDB（原華為云 GaussDBNoSQL，后統稱為 GeminiDB）是采用存算分離架構的 NoSQL 多模數據庫，在性能、穩定性方面業界領先。KV 接口上，GeminiDB 100%兼容 Redis 5.0 協議，用戶無需修改代碼即可平遷到 GeminiDB。針對業界的 Redisfork 技術痛點，GeminiDB 提供了終極的優化方案。

我們先來看下業界的兩種通用解法：

業界解法一

實現層面優化 fork 問題

常規的解決方案是在 fork 實現層進行魔改，也就是找到造成 fork 長尾時延的代碼所在然后對其進行優化。通過多次實驗發現，fork 的執行時間隨著實例大小增長而劇增，其中最耗時的是頁表拷貝操作，如下圖(a)所示，在 Invoke Fork 操作之后，主進程需要花時間進行頁表拷貝，服務出現毛刺現象。

由此產生 fork 重寫的核心思路：由于父進程在 fork 原生內部實現中并不純粹，其在頁表復制時仍需陷入內核態，出現短暫阻塞現象。通過將父進程耗時占比最高的頁拷貝操作移至子進程去執行，足以大幅削弱父進程在 fork 過程中的阻塞現象，從而可以在對程序無任何修改的條件下解決原生 fork 帶來的長尾時延。

業界有種算法，如上圖(b)所示，可以通過讓子進程去異步完成頁表拷貝動作(Copy Page Table)和主進程主動同步頁表(Proactively Synchronize)來解決毛刺以及主子進程的可能不一致問題，可以做到主進程近乎零阻塞。不難看出，修改 fork 算法有以下幾點優勢:

1.實現層面消除了 fork 場景帶來的長尾時延。

2.對內存型鍵值存儲服務完全透明。

但由于涉及魔改操作系統 fork 實現，導致維護和演進成本較高，向前兼容性較差。相比之下，在架構層面去解決這個問題，或許更加簡單且自然。

業界解法二

架構層面優化 fork 問題

除了針對 fork 的優化，直接消除 fork 或許是工程上更加迫切的需要。

我們分析一下，之所以會有 fork 的引入，是因為 Redis 做了 AOF 重寫、RDB、主從同步的操作。恰恰對于 Redis 這種內存型 KV 存儲而言，AOF 操作可以保證了數據不丟，而 RDB 和主從同步也是其持久化需要。但如果是非易失型 KV 存儲，從內存到持久化介質的鏈路就不存在，類 RDB 和類主從同步操作也就可以交給存儲層獨立解決，從而徹底消除 fork 所帶來的長尾時延。

基于此，業界有些數據庫將 KV 數據通過其存儲引擎直接寫入持久化介質中，且在計算層做了性能上的高度優化，達到了不劣于開源 Redis 的性能：

以 PMem 為存儲底座的存算分離架構

采用 PMem 作為其主要持久化存儲介質的存儲引擎，在某種程度上來說，其兼具 DRAM 的性能和字節尋址能力以及 SSD 的可持久化特性。下圖是幾種存儲介質的對比：

同時，通過實現存儲引擎的 Cache 模塊，在服務運行期間存放業務熱數據的數據頁會被加載到 PMem 上，在處理用戶請求期間不再直接操作 SSD 上的數據頁，而是操作讀寫延遲更低的 PMem，使得計算層的性能以及吞吐量得到了進一步的提升。

總的來說，使用 PMem 存儲底座的優勢在于：

1.沒有 fork 場景，不存在 fork 帶來的長尾時延。

2.提供了比開源 Redis 更大的容量。

3.數據可冷熱分級存儲。

但是，強依賴 PMem 也帶來了一些難以解決的問題：

1.非易失型內存編程難度高且魯棒性差，需要框架和工具層面去降低其開發難度，總的來說，開發和維護成本過高。

2.由于編程復雜，而且 Redis 索引結構繁多，數據模型相關 API 高達 300 多個，造成 Redis 命令兼容的實現可靠性極具下降，同樣面臨如何降低編碼復雜度的問題。

3.PMem 相比于 DRAM 有數量級的性能下降，在讀性能上有 3 倍以上的性能下降以及 10 倍以上的帶寬減少，性能問題不可忽視。

在可靠性和開發維護成本上，以 PMem 為存儲底座的架構還是有一定不足之處。

華為云的 NoSQL 數據庫 GeminiDB 在這方面有更加強大的實現方案。GeminiDB 兼容 Redis 接口（原 GaussDB(for Redis)，后統稱為 GeminiDB 兼容 Redis 接口），以 RocksDB+分布式文件系統+高性能存儲池為底座，實現了領先的存算分離架構，綜合表現更佳。

三、華為云 GeminiDB 方案介紹

GeminiDB 存算分離架構

華為云 GeminiDB 兼容 Redis 接口，存儲架構采用 RocksDB+分布式文件系統+高性能存儲池，如下圖所示，在架構層面消除了長尾時延的影響外，通過高性能存儲池提供高可靠存儲特性，分布式文件系統封裝高性能存儲池向外暴露類標準文件系統接口，降低開發難度。

而在性能選擇方面，選擇 RocksDB 作為存儲引擎。它針對快速、低延遲的存儲進行了優化，具有極高的寫入吞吐。同時，RocksDB 支持預寫日志，范圍掃描和前綴搜索，在高并發讀寫以及大容量存儲時能夠提供一致性的保證。RockDB 的追加寫特征恰好解決了磁盤 I/O 最耗時磁盤尋道時間，達到了接近內存隨機讀寫的性能。

高可靠的實現，選擇華為研發的高性能存儲池分布式存儲，最高支持 128TB 的海量存儲，支持跨 AZ 部署、故障秒級切換，保證了在極度惡劣的情況的數據無損和快速恢復，支持數據的自動備份。

除此之外，分布式文件系統借助 HDFS Snapshot 實現了秒級快照，產生整個文件系統或某個目錄在某個時刻的鏡像，向用戶提供了數據恢復、數據備份、數據測試的能力。

簡言之，通過 RocksDB+分布式文件系統+高性能存儲池的存儲架構，已經做到：

1.低時延，基于高性能的存儲架構，訪問時延有了高度保障。

2.大容量，基于存算分離，存儲層可自由擴容。

3.低成本，基于冷熱數據分級存儲，貼合客戶訴求。

4.高可靠， 基于分布式文件系統+高性能存儲池，支持優秀的數據備份和數據同步特性，且不對主進程造成時延影響。

不過，RocksDB 的數據存儲模式也會帶來一些復雜性。由于 RocksDB 存在讀、寫和空間放大的問題，且三者相互制約。盡管 RocksDB 提供了多種 Compaction 策略和參數以適應不同應用場景，但由于影響因子過多，策略的選擇和調參成本會比較高。

小結

通過不同解決方案之間的對比，在解決長尾時延的問題上，架構解決方案更加貼合大多數客戶訴求。同時，在大部分場景下，GeminiDB 兼容 Redis 接口的架構相比于業界方案提供了更高的可靠性和良好的性能表現，預計年底可達到單片百萬 QPS 的性能水平。

開年采購季云數據庫特惠
活動時間：3月1日-31日
云數據庫新用戶1年19元起
不限新老1年6.5折起

審核編輯 黃宇