技術(shù)背景

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

華為云 GeminiDB（原華為云 GaussDBNoSQL，后統(tǒng)稱為 GeminiDB）是采用存算分離架構(gòu)的 NoSQL 多模數(shù)據(jù)庫，在性能、穩(wěn)定性方面業(yè)界領(lǐng)先。KV 接口上，GeminiDB 100%兼容 Redis 5.0 協(xié)議，用戶無需修改代碼即可平遷到 GeminiDB。針對業(yè)界的 Redisfork 技術(shù)痛點，GeminiDB 提供了終極的優(yōu)化方案。

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

業(yè)界解法一

實現(xiàn)層面優(yōu)化 fork 問題

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

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

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

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

2.對內(nèi)存型鍵值存儲服務(wù)完全透明。

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

業(yè)界解法二

架構(gòu)層面優(yōu)化 fork 問題

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

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

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

以 PMem 為存儲底座的存算分離架構(gòu)

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

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

總的來說，使用 PMem 存儲底座的優(yōu)勢在于：

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

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

3.數(shù)據(jù)可冷熱分級存儲。

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

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

2.由于編程復雜，而且 Redis 索引結(jié)構(gòu)繁多，數(shù)據(jù)模型相關(guān) API 高達 300 多個，造成 Redis 命令兼容的實現(xiàn)可靠性極具下降，同樣面臨如何降低編碼復雜度的問題。

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

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

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

三、華為云 GeminiDB 方案介紹

GeminiDB 存算分離架構(gòu)

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

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

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

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

簡言之，通過 RocksDB+分布式文件系統(tǒng)+高性能存儲池的存儲架構(gòu)，已經(jīng)做到：

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

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

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

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

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

小結(jié)

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

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

審核編輯 黃宇