作者簡介

patpatbear，攜程軟件技術(shù)專家，負(fù)責(zé)攜程緩存內(nèi)核的維護(hù)，熱愛開源，專注于高性能、分布式NoSQL系統(tǒng)的建設(shè)和應(yīng)用。

一、背景

redis使用內(nèi)存作為存儲介質(zhì)，具有良好的性能和低延遲，但其內(nèi)存容量通常成為瓶頸，且內(nèi)存價(jià)格較高，導(dǎo)致redis使用成本較高。

隨著SSD磁盤性能的不斷提高，NVMe SSD的隨機(jī)讀寫延遲也僅有幾十微秒，與redis的固有延遲（100~200us）相當(dāng)，用SSD作為存儲介質(zhì)也可以達(dá)到較低的延遲，同時(shí)節(jié)省成本。

因此我們研發(fā)了ROR(Redis-On-Rocks)產(chǎn)品，通過對redis內(nèi)核增強(qiáng)以支持?jǐn)?shù)據(jù)冷熱交換，使用磁盤擴(kuò)展緩存容量，可節(jié)省約2/3成本，而性能也能滿足大多數(shù)業(yè)務(wù)需求。

二、ROR簡介

ROR核心思路很簡單：在redis codebase基礎(chǔ)上擴(kuò)展冷熱交換功能，實(shí)現(xiàn)redis數(shù)據(jù)冷熱多級存儲，降低緩存的綜合使用成本。

ROR將數(shù)據(jù)分為冷熱兩部分：

• 熱數(shù)據(jù)沿用redis引擎，使用內(nèi)存存儲，數(shù)據(jù)結(jié)構(gòu)和原生redis完全一致
• 冷數(shù)據(jù)選用RocksDB引擎，使用磁盤存儲，以subkey為粒度存儲在RocksDB中

ROR負(fù)責(zé)冷熱數(shù)據(jù)的交換：

• 換入（從RocksDB到redis）：當(dāng)客戶端訪問冷數(shù)據(jù)，則將RocksDB中的數(shù)據(jù)換入到redis中，ROR把命令依賴的數(shù)據(jù)換入到redis，后續(xù)命令執(zhí)行與原生redis一致。
• 換出（從redis到RocksDB）：當(dāng)內(nèi)存用量超過maxmemory之后，則將熱數(shù)據(jù)換出到RocksDB中，ROR冷熱交換算法采用了redis原生的LFU算法，原本被redis evict的數(shù)據(jù)將被交換到內(nèi)存中。
  

由于ROR繼承了redis的數(shù)據(jù)結(jié)構(gòu)和命令實(shí)現(xiàn)，只負(fù)責(zé)冷熱數(shù)據(jù)交換，因此可以兼容幾乎所有的redis命令，可快速跟進(jìn)redis官方新特性。

三、與RoF對比

從長遠(yuǎn)發(fā)展考慮，redis是事實(shí)上的緩存標(biāo)準(zhǔn)，緩存內(nèi)核基于社區(qū)開源redis更便于跟進(jìn)社區(qū)redis演進(jìn)，因此ROR選擇了基于redis基礎(chǔ)上擴(kuò)展冷熱交換能力。

RedisLabs的商業(yè)產(chǎn)品Redis-on-Flash(RoF)與ROR設(shè)計(jì)思路類似，但是調(diào)研之后，我們發(fā)現(xiàn)RoF在成本、通用性、性能等方面并不能滿足我們的需求。

3.1 成本

RoF把value保存在磁盤、key保留在內(nèi)存主表，可以方便地兼容dbsize、scan、randomkey等命令，但占用的內(nèi)存量會隨著dbsize線性上升。

冷數(shù)據(jù)key保存在內(nèi)存主表（hashtable），每個(gè)key的輔助指針、robj等平均占用約50B，生產(chǎn)String類型平均value大小為512B。從成本的角度看，按照key占內(nèi)存10%，value占90%計(jì)算

• 換出80%value，可減少72% (80%*90%) 內(nèi)存
• 換出80%冷key，可繼續(xù)減少29% (10%*80%/(100%-72%))內(nèi)存

因此ROR并不把冷數(shù)據(jù)的key保存在內(nèi)存，而是保存到RocksDB中單獨(dú)的meta column family。

考慮到meta  column family訪問比較頻繁，且只存儲type、expire之類的少量元數(shù)據(jù)，因此用少量內(nèi)存(block cache)可以緩存多數(shù)冷key。

經(jīng)驗(yàn)證，分配256MB block cache后，把冷數(shù)據(jù)的key存儲到RocksDB并不會降低整體QPS，但會增加IO線程的CPU消耗，由于redis宿主機(jī)cpu利用率只有10%，用cpu換內(nèi)存是可以接受的。

3.2 通用性

為了避免重復(fù)緩存，RoF禁用了RocksDB層的table cache和文件系統(tǒng)層的page cache。這意味著訪問冷key時(shí)必須進(jìn)行IO操作，因此冷key和熱key的訪問延遲會有較大區(qū)別。

為了提高通用性，ROR合理利用RocksDB層的table cache和操作系統(tǒng)層的page cache，盡可能利用未被占用的內(nèi)存，減少訪問冷key和熱key之間的延遲差距。

實(shí)際上，無論是DBA還是業(yè)務(wù)方，都很難準(zhǔn)確預(yù)測緩存集群是否存在明顯的冷熱特征。ROR適用于通用場景，能夠大大減少溝通成本和業(yè)務(wù)方關(guān)于延遲的擔(dān)憂。

在redis遷移至ROR時(shí)，我們并不評估應(yīng)用程序是否具有冷熱特征，只要業(yè)務(wù)QPS在redis的一半以下，對P99延遲不是非常敏感，就可以將其遷移到ROR。

3.3 性能

RoF按key粒度存儲，key與RocksDB key一一對應(yīng)；而ROR按subkey粒度存儲，subkey都與RocksDB key一一對應(yīng)。

對于HSET、HGET等聚合類型命令，RoF需要換入換出整個(gè)key，而ROR只讀寫必要的subkey，因此讀寫放大遠(yuǎn)低于RoF，QPS和延遲也優(yōu)于RoF。

以下為ROR、RoF在大壓力（100線程不限QPS）和普通壓力（1000線程10000QPS），讀寫純冷數(shù)據(jù)的QPS和延遲。可以看出：

• 大壓力情況下，ROR HGET、HSET命令QPS約為RoF的2~3倍
• 普通壓力情況下，ROR延遲約300~500us，遠(yuǎn)低于RoF 14~120ms 延遲
  

測試說明：

• 數(shù)據(jù)：hash：5,000,000 (key count) * 2KB (per key，5個(gè)field，每個(gè)filed 400B)
• 配置：ROR的maxmemory設(shè)置為200MB；RoF有最小內(nèi)存限制，設(shè)置為2G
• 場景：a）100thd：壓力測試，100客戶端并發(fā)，不限速測試；b）1wqps：模擬常規(guī)訪問，1000客戶端，限速1W QPS測試

對于超大的聚合key，RoF將整個(gè)key加載到內(nèi)存中，會有明顯的延遲尖刺（可達(dá)秒級）；而ROR只將必要的subkey換入內(nèi)存，則不會有明顯的延遲尖刺。

多數(shù)使用redis的業(yè)務(wù)對延遲比較敏感，不能接受過大延遲尖刺。

測試說明：

• hash：共有1,000,000個(gè)元素，每個(gè)元素128B
• list：共有1,000,000個(gè)元素，每個(gè)元素128B

四、實(shí)現(xiàn)方案

4.1 冷熱交換

以下是客戶端訪問到冷key時(shí)ROR的處理過程。其中藍(lán)色模塊與原生redis相同，橙色模塊為ROR新增的冷熱交換功能。

總體上ROR先冷熱交換（swap），再執(zhí)行命令處理流程。

冷熱交換（swap）過程主要分為以下步驟：

1）語法分析：分析客戶端命令涉及哪些key和subkey。比如，可以分析出MGET k1 k2 k3依賴于k1,k2,k3；而HMGET h1 f1 f2 f3，依賴于 h1.{ f1, f2, f3 }。

2）加鎖：根據(jù)語法分析出的結(jié)果，對命令所依賴的key加鎖。值得注意的是，這里的鎖并不是pthread_mutex之類的線程鎖，而是ROR項(xiàng)目實(shí)現(xiàn)的一種單線程鎖，本質(zhì)上是一個(gè)等待隊(duì)列，詳細(xì)介紹參考后續(xù)并發(fā)控制章節(jié)。 

3）提交SWAP任務(wù)：拿到鎖之后，提交swap任務(wù)到IO線程組執(zhí)行RocksDB讀寫。

4）執(zhí)行RocksDB讀寫：IO線程組執(zhí)行RocksDB讀操作。

5）合并數(shù)據(jù)：將RocksDB讀取的數(shù)據(jù)合并到redis中。

經(jīng)過swap過程之后，冷數(shù)據(jù)已經(jīng)換入到redis，后續(xù)執(zhí)行命令與原生redis一致。

4.2 并發(fā)控制

redis架構(gòu)上為單主線程，而RocksDB提供的是阻塞模式的API，直接使用redis主線程調(diào)用RocksDB將極大降低redis的性能。為了提高IO吞吐，ROR使用了額外的IO線程組執(zhí)行RocksDB讀寫。由于增加了IO線程組，對于同一key的讀寫不再是單線程，如果不加控制，那么數(shù)據(jù)將變得錯(cuò)亂。

為了控制并發(fā)，ROR設(shè)計(jì)實(shí)現(xiàn)了一種單線程可重入鎖來保證同一時(shí)間對同一key只有一個(gè)客戶端在進(jìn)行IO交換。這里的鎖并不是pthread_mutex這種系統(tǒng)線程鎖，其本質(zhì)是一個(gè)等待隊(duì)列：當(dāng)key被鎖定后，嘗試獲取該鎖的客戶端必須等待前序客戶端釋放鎖之后才能獲取到key的鎖。

如下圖所示，C1、C2、C3三個(gè)客戶端先后執(zhí)行了MGET命令，其中Key1、Key2、Key3均為冷數(shù)據(jù)。

C1依賴Key1、Key2，由于這2個(gè)key未被鎖定且為冷，因此C1獲取到Key1、Key2的鎖，并觸發(fā)了Key1、Key2換入；

C2依賴Key2、Key3，由于Key2被C1鎖定，因此C2等待C1執(zhí)行結(jié)束才能獲取key2鎖；Key3未被鎖定且為冷，因此C2獲取到了Key2的鎖，并觸發(fā)了Key3換入；

C3依賴Key1、key3，由于Key1、Key3分別被C1、C2鎖定，因此C3等待C1、C2執(zhí)行結(jié)束后才能獲取Key1、Key3鎖。

因此最終換入Key1、Key2、Key3換入后，客戶端執(zhí)行順序?yàn)镃1=>C2=>C3。

以上是一個(gè)簡單的示例，ROR為了實(shí)現(xiàn)FLUSHDB/BGSAVE之類涉及整個(gè)keyspace的命令并發(fā)控制需求，等待隊(duì)列包含KEY、DB、SVR三種粒度的鎖，大粒度的鎖需等待細(xì)粒度鎖釋放后才能獲得。此外為了確保MULTI/EXEC事務(wù)不產(chǎn)生死鎖，允許同一個(gè)事務(wù)重復(fù)鎖定同一key（亦即可重入）。

如下圖所示，C1、C2兩個(gè)客戶端先后發(fā)起2個(gè)事務(wù)。

C1依賴Key1（2次），由于C1在同一事務(wù)中依賴Key1（2次）且為冷，因此C1獲得Key1鎖并觸發(fā)換入；

C2依賴Key2（2次）、DB0、SVR鎖，由于C2在同一事務(wù)中依賴Key2（2次）且為冷，因此C2獲得Key2鎖并觸發(fā)換入；注意由于C2依賴DB0鎖，DB0鎖范圍大約Key1、Key2，因此只有C1釋放Key1之后才能獲得DB0鎖。

假設(shè)Key1先于Key2被換入，Key1換入后，C1事務(wù)得到執(zhí)行并釋放Key1鎖。

當(dāng)Key2換入后，C2獲得DB0鎖以及SVR鎖（獲得所有鎖），C2事務(wù)得到執(zhí)行。

4.3 冷數(shù)據(jù)存儲

與業(yè)界多數(shù)方案一樣，ROR的冷數(shù)據(jù)存儲采用了RocksDB引擎，設(shè)計(jì)上參考了kvrocks、pika等項(xiàng)目，主要有3個(gè)要點(diǎn)：

• key存儲到RocksDB
• subkey與RocksDB KV對應(yīng)（i.e. 按subkey存儲）
• lazy刪除聚合類型key

key存儲到RocksDB

ROR為了做到內(nèi)存消耗與dbsize無關(guān)，內(nèi)存中并不會存儲冷key，key類型、expire、version等信息會存儲到RocksDB的metaCF中。這樣設(shè)計(jì)主要是考慮每個(gè)key需要額外消耗約50B，如果dbsize為1億則需要額外消耗約5GB內(nèi)存。對dbsize大、value小的集群來講，額外消耗的內(nèi)存過多，冷熱分離的性價(jià)比則不高。

因此ROR和RoF不同，不會把冷key存儲在內(nèi)存中，少量與key相關(guān)（scan、randomkey、dbsize）命令，則進(jìn)行適配性改造。

subkey與RocksDB KV對應(yīng)

RocksDB的數(shù)據(jù)類型只有KV，與redis支持hash、set、zset等聚合類型key不能一一對應(yīng)，因此需要構(gòu)造redis聚合類型key與RocksDB KV類型之間的對應(yīng)關(guān)系。

最直接的方案是將redis的聚合類型key直接序列化單個(gè)為RocksDB KV，但這種方案的缺點(diǎn)非常明顯，即HGET hash subkey只依賴單個(gè)subkey的命令，也需要將整個(gè)聚合類型key換入到內(nèi)存，這會造成嚴(yán)重的讀寫放大。

因此ROR將聚合類型的subkey存儲為RocksDB KV，換入聚合類型數(shù)據(jù)冷key只需要換入必要的subkey。

lazy刪除聚合類型key

對于聚合類型key而言，每個(gè)subkey對應(yīng)RocksDB KV，ROR刪除聚合key需要?jiǎng)h除掉所有的subkey，直接從RocksDB中迭代刪除復(fù)雜度為O(N)，會造成延遲尖刺。

參考pika、kvrocks的設(shè)計(jì)，聚合類型key都有版本號，ROR刪除聚合key時(shí)，只刪掉metaCF的元數(shù)據(jù)，而其他subkey則在RocksDB compaction中通過compaction filter逐漸過濾刪除。

hash/set/zset編碼

以下是hash/set類型的編碼格式：

每個(gè)hash/set在metaCF有1個(gè)RocksDB KV，記錄了類型、超時(shí)時(shí)間、版本以及subkey數(shù)量。

每個(gè)hash/set在defaultCF有N個(gè)RocksDB KV，每個(gè)subkey對應(yīng)一個(gè)。由于每個(gè)subkey都記錄了對應(yīng)的version，因此刪除聚合key只需要把metaCF的KV刪掉即完成lazy刪除。

zset類型的編碼格式類似，只多了scoreCF記錄zset的score排序。

list編碼

由于與hash/set/zset的操作差別較大，list數(shù)據(jù)模型設(shè)計(jì)上也有所差別。設(shè)計(jì)上，ROR內(nèi)存中的list仍復(fù)用redis數(shù)據(jù)結(jié)構(gòu)，且list可能只有部分subkey在內(nèi)存中。

模型上list的設(shè)計(jì)如下：

• list為任意段rockslist（冷）和memlist（熱）的組合
• list元素要么在memlist、要么在rockslist，memlist沒有交集
• 分段信息存儲在listObjectMeta.segments中，segments的每個(gè)元素表示一段，記錄了每段的類型以及長度。

rockslist也按subkey粒度存儲在RocksDB中。

4.4 cuckoo filter減少IO

前面提到ROR為了做到內(nèi)存用量與dbsize無關(guān)，key元信息不存儲在內(nèi)存中，因此如果客戶端訪問的key不是熱數(shù)據(jù)，則必須查詢RocksDB才能確認(rèn)key是否存在：對于key存在的情況，讀RocksDB并換入冷數(shù)據(jù)是必要的；但如果key不存在，則讀RocksDB是非必要的。特別是當(dāng)業(yè)務(wù)keyspace miss率高的情況（比如重復(fù)讀不存在的key），存在大量的非必要IO情況，降低了整體性能。

對于過濾不存在key問題，用bloom filter能以8~10 bit per key的內(nèi)存取得很好的過濾效果，但由于bloom filter不支持刪除，而ROR的keyspace始終處于動(dòng)態(tài)變化中，因此bloom filter功能上無法滿足需求。

經(jīng)過調(diào)研之后，我們發(fā)現(xiàn)cuckoo filter可以很好地滿足我們的需求，支持刪除并且內(nèi)存消耗量僅需8 bit per key即可滿足ROR過濾準(zhǔn)確度需求。

由于無法預(yù)測準(zhǔn)確到key數(shù)量，ROR實(shí)現(xiàn)cuckoo filter時(shí)采用了多個(gè)容量指數(shù)增長的cuckoo filter組成的cascading cuckoo filter。

經(jīng)過測試我們發(fā)現(xiàn)，對于keyspace miss場景，cuckoo filter可以將ROR的QPS從5W提升到6W左右，吞吐提升約20%；對于keyspace hit場景則無明顯影響。

4.5 兼容redis復(fù)制

ROR的復(fù)制協(xié)議完全兼容redis原生復(fù)制，全量復(fù)制采用RDB格式，增量復(fù)制使用RESP協(xié)議。由于完全兼容redis原生復(fù)制協(xié)議，ROR可以直接對接xpipe，具備DR能力。

流式全量復(fù)制

ROR與Redis全量復(fù)制主要流程相同：master fork出child進(jìn)程，由child進(jìn)程打RDB。ROR由于有冷熱兩類數(shù)據(jù)，因此生成RDB的與原生Redis有區(qū)別：

• 熱數(shù)據(jù)生成RDB方案不變
• 冷數(shù)據(jù)先獲取RocksDB CHECKPOINT，然后SCAN冷數(shù)據(jù)轉(zhuǎn)換為RDB格式
  
  

冷數(shù)據(jù)（RocksDB部分）生成RDB的一種方案是將冷key臨時(shí)加載內(nèi)存，復(fù)用redis的序列化方法構(gòu)造RDB，但這種方案加載全部冷key會消耗大量CPU，當(dāng)遇到redis宿主機(jī)宕機(jī)重啟，大量redis全量同步爭用CPU將導(dǎo)致全量同步時(shí)間過長。

出于性能考慮，ROR構(gòu)造RDB并不加載冷key，而是采用了流式構(gòu)造RDB的方案：使用一個(gè)IO線程迭代RocksDB全量數(shù)據(jù)，并將迭代的數(shù)據(jù)流式append到RDB中。需要注意的是，流式構(gòu)造RDB依賴于ROR在存儲設(shè)計(jì)上將同一個(gè)聚合類型key的subkey存儲在RocksDB相鄰位置。

實(shí)現(xiàn)層面，流式構(gòu)造RDB方案避免了把key加載到內(nèi)存并跳過redis層重新編碼，直接將RockDB數(shù)據(jù)流式填充到rdb，全量復(fù)制速度315MB/s，可以達(dá)到redis復(fù)制性能（390MB/s）的80%左右。

并發(fā)增量復(fù)制

redis增量復(fù)制過程中，master通過單個(gè)復(fù)制客戶端推送復(fù)制流到slave。由于復(fù)制客戶端只有1個(gè)（冷熱交換最大并發(fā)為1）如果ROR slave直接用復(fù)制客戶端交換數(shù)據(jù)，會出現(xiàn)slave復(fù)制無法跟上master寫入。

為了提高復(fù)制交換性能，ROR將從復(fù)制客戶端將收到的命令分發(fā)到多個(gè)worker客戶端，并發(fā)執(zhí)行交換。

如果worker客戶端在交換結(jié)束后直接調(diào)用命令，那么slave上命令執(zhí)行的順序可能與master不同，造成主從數(shù)據(jù)不一致。

ROR采用的方案下，worker客戶端交換結(jié)束后并不立即執(zhí)行命令，而是等到前序命令全部執(zhí)行完之后在執(zhí)行。由于slave執(zhí)行增量復(fù)制命令與master向下傳播的復(fù)制流的命令順序一致，可以確保主從數(shù)據(jù)一致。

如上圖所示，①、②、④在并發(fā)執(zhí)行IO操作，雖然②、④可能在①之前完成數(shù)據(jù)交換，但一定會等到①完成IO后再執(zhí)行命令。

ROR增量復(fù)制并發(fā)改造后，slave處理復(fù)制命令速度從幾千QPS提升到大于master的最大寫入速度（5~10W QPS左右，與冷熱數(shù)據(jù)占比相關(guān)）。

五、生產(chǎn)實(shí)踐

從經(jīng)驗(yàn)來看，多數(shù)redis集群QPS較低但內(nèi)存用量較大，redis宿主機(jī)通常因?yàn)檫_(dá)到內(nèi)存上限觸發(fā)擴(kuò)容，但CPU資源則比較空閑，比如攜程內(nèi)redis宿主機(jī)平均CPU使用率約15%，但平均內(nèi)存使用率達(dá)到50%。

ROR采用磁盤增加了緩存容量，能容納更多的數(shù)據(jù)量，但RocksDB引擎的compaction和壓縮會消耗更多的CPU資源，因此ROR可以認(rèn)為是用空閑的CPU換內(nèi)存的成本解決方案。

成本方面，經(jīng)驗(yàn)數(shù)據(jù)顯示1個(gè)ROR實(shí)例可容納3個(gè)redis實(shí)例的數(shù)據(jù)，因此redis遷ROR能節(jié)省2/3的成本。

目前在ROR在生產(chǎn)部署了幾萬個(gè)實(shí)例。由于海外公有云內(nèi)存單價(jià)高，已基本全部部署為ROR，每年可以節(jié)省成本上千萬元。

性能方面，從吞吐量考慮，攜程內(nèi)部redis集群高QPS占比較低，遠(yuǎn)低于ROR的QPS上限（參考上文性能數(shù)據(jù)）。

從延遲考慮，ROR設(shè)計(jì)上合理利用緩存，按subkey粒度存儲，且硬件上nvme SSD延遲只有幾十微秒，因此與Redis相比延遲并沒有特別明顯的上升。

以下為一個(gè)典型redis集群遷移ROR后延遲對比，其中80%為冷數(shù)據(jù)、20%為熱數(shù)據(jù)，遷移前后客戶端訪問延遲從200us變?yōu)?20us左右。

六、項(xiàng)目開源與未來計(jì)劃

6.1 項(xiàng)目開源

目前ROR(Redis-On-Rocks)已開源，采用與Redis一致的BSD協(xié)議。

6.2 未來計(jì)劃

1）提升單實(shí)例QPS

部分業(yè)務(wù)場景（比如大數(shù)據(jù)相關(guān)業(yè)務(wù)）不但數(shù)據(jù)量大，而且QPS也比較高，這些集群可能出現(xiàn)ROR主線程100%情況。針對這些場景，我們考慮從軟硬件2個(gè)層面優(yōu)化，軟件層面考慮減少冷熱交換損耗、自動(dòng)化pipeline減少網(wǎng)絡(luò)CPU消耗；硬件層面使用更高主頻的CPU提升上限。

2）完善數(shù)據(jù)結(jié)構(gòu)支持

部分使用頻次較少的數(shù)據(jù)結(jié)構(gòu)待優(yōu)化，比如：bitmap目前按照string處理，讀寫放大比較大，待優(yōu)化性能；stream目前尚未支持，使用內(nèi)存存儲，待支持。

3）減少全量同步

國內(nèi)與海外的帶寬比較小，如果出現(xiàn)全量同步則海外業(yè)務(wù)受影響時(shí)間會比較久。隨著隨著海外部署量上升，這個(gè)問題的影響性逐步增大，后續(xù)ROR考慮提供可用性與一致性的選項(xiàng)，允許少量數(shù)據(jù)不一致的情況下增量同步。