淺析 KV 存儲之長尾時(shí)延問題，探尋行業(yè)更優(yōu)解決方案！

技術(shù)背景

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

華為云 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ù)痛點(diǎn)，GeminiDB 提供了終極的優(yōu)化方案。

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

業(yè)界解法一

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

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

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

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

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

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

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

業(yè)界解法二

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

三、華為云 GeminiDB 方案介紹

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

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

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

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

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

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

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

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

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

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

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

小結(jié)

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

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

審核編輯 黃宇