技術(shù)背景

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

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

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

業(yè)界解法一

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

常規(guī)的解決方案是在 fork 實(shí)現(xiàn)層進(jìn)行魔改，也就是找到造成 fork 長(zhǎng)尾時(shí)延的代碼所在然后對(duì)其進(jìn)行優(yōu)化。通過多次實(shí)驗(yàn)發(fā)現(xiàn)，fork 的執(zhí)行時(shí)間隨著實(shí)例大小增長(zhǎng)而劇增，其中最耗時(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)象，從而可以在對(duì)程序無任何修改的條件下解決原生 fork 帶來的長(zhǎng)尾時(shí)延。

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

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

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

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

業(yè)界解法二

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

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

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

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

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

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

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

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

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

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

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

但是，強(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ù)量級(jí)的性能下降，在讀性能上有 3 倍以上的性能下降以及 10 倍以上的帶寬減少，性能問題不可忽視。

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

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

三、華為云 GeminiDB 方案介紹

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

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

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

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

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

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

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

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

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

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

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

小結(jié)

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

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

審核編輯 黃宇