作者簡介

patpatbear，攜程軟件技術專家，負責攜程緩存內核的維護，熱愛開源，專注于高性能、分布式NoSQL系統的建設和應用。

一、背景

redis使用內存作為存儲介質，具有良好的性能和低延遲，但其內存容量通常成為瓶頸，且內存價格較高，導致redis使用成本較高。

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

因此我們研發了ROR(Redis-On-Rocks)產品，通過對redis內核增強以支持數據冷熱交換，使用磁盤擴展緩存容量，可節省約2/3成本，而性能也能滿足大多數業務需求。

二、ROR簡介

ROR核心思路很簡單：在redis codebase基礎上擴展冷熱交換功能，實現redis數據冷熱多級存儲，降低緩存的綜合使用成本。

ROR將數據分為冷熱兩部分：

• 熱數據沿用redis引擎，使用內存存儲，數據結構和原生redis完全一致
• 冷數據選用RocksDB引擎，使用磁盤存儲，以subkey為粒度存儲在RocksDB中

ROR負責冷熱數據的交換：

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

由于ROR繼承了redis的數據結構和命令實現，只負責冷熱數據交換，因此可以兼容幾乎所有的redis命令，可快速跟進redis官方新特性。

三、與RoF對比

從長遠發展考慮，redis是事實上的緩存標準，緩存內核基于社區開源redis更便于跟進社區redis演進，因此ROR選擇了基于redis基礎上擴展冷熱交換能力。

RedisLabs的商業產品Redis-on-Flash(RoF)與ROR設計思路類似，但是調研之后，我們發現RoF在成本、通用性、性能等方面并不能滿足我們的需求。

3.1 成本

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

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

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

因此ROR并不把冷數據的key保存在內存，而是保存到RocksDB中單獨的meta column family。

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

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

3.2 通用性

為了避免重復緩存，RoF禁用了RocksDB層的table cache和文件系統層的page cache。這意味著訪問冷key時必須進行IO操作，因此冷key和熱key的訪問延遲會有較大區別。

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

實際上，無論是DBA還是業務方，都很難準確預測緩存集群是否存在明顯的冷熱特征。ROR適用于通用場景，能夠大大減少溝通成本和業務方關于延遲的擔憂。

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

3.3 性能

RoF按key粒度存儲，key與RocksDB key一一對應；而ROR按subkey粒度存儲，subkey都與RocksDB key一一對應。

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

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

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

測試說明：

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

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

多數使用redis的業務對延遲比較敏感，不能接受過大延遲尖刺。

測試說明：

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

四、實現方案

4.1 冷熱交換

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

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

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

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

2）加鎖：根據語法分析出的結果，對命令所依賴的key加鎖。值得注意的是，這里的鎖并不是pthread_mutex之類的線程鎖，而是ROR項目實現的一種單線程鎖，本質上是一個等待隊列，詳細介紹參考后續并發控制章節。 

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

4）執行RocksDB讀寫：IO線程組執行RocksDB讀操作。

5）合并數據：將RocksDB讀取的數據合并到redis中。

經過swap過程之后，冷數據已經換入到redis，后續執行命令與原生redis一致。

4.2 并發控制

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

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

如下圖所示，C1、C2、C3三個客戶端先后執行了MGET命令，其中Key1、Key2、Key3均為冷數據。

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

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

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

因此最終換入Key1、Key2、Key3換入后，客戶端執行順序為C1=>C2=>C3。

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

如下圖所示，C1、C2兩個客戶端先后發起2個事務。

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

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

假設Key1先于Key2被換入，Key1換入后，C1事務得到執行并釋放Key1鎖。

當Key2換入后，C2獲得DB0鎖以及SVR鎖（獲得所有鎖），C2事務得到執行。

4.3 冷數據存儲

與業界多數方案一樣，ROR的冷數據存儲采用了RocksDB引擎，設計上參考了kvrocks、pika等項目，主要有3個要點：

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

key存儲到RocksDB

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

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

subkey與RocksDB KV對應

RocksDB的數據類型只有KV，與redis支持hash、set、zset等聚合類型key不能一一對應，因此需要構造redis聚合類型key與RocksDB KV類型之間的對應關系。

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

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

lazy刪除聚合類型key

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

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

hash/set/zset編碼

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

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

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

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

list編碼

由于與hash/set/zset的操作差別較大，list數據模型設計上也有所差別。設計上，ROR內存中的list仍復用redis數據結構，且list可能只有部分subkey在內存中。

模型上list的設計如下：

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

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

4.4 cuckoo filter減少IO

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

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

經過調研之后，我們發現cuckoo filter可以很好地滿足我們的需求，支持刪除并且內存消耗量僅需8 bit per key即可滿足ROR過濾準確度需求。

由于無法預測準確到key數量，ROR實現cuckoo filter時采用了多個容量指數增長的cuckoo filter組成的cascading cuckoo filter。

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

4.5 兼容redis復制

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

流式全量復制

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

• 熱數據生成RDB方案不變
• 冷數據先獲取RocksDB CHECKPOINT，然后SCAN冷數據轉換為RDB格式
  
  

冷數據（RocksDB部分）生成RDB的一種方案是將冷key臨時加載內存，復用redis的序列化方法構造RDB，但這種方案加載全部冷key會消耗大量CPU，當遇到redis宿主機宕機重啟，大量redis全量同步爭用CPU將導致全量同步時間過長。

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

實現層面，流式構造RDB方案避免了把key加載到內存并跳過redis層重新編碼，直接將RockDB數據流式填充到rdb，全量復制速度315MB/s，可以達到redis復制性能（390MB/s）的80%左右。

并發增量復制

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

為了提高復制交換性能，ROR將從復制客戶端將收到的命令分發到多個worker客戶端，并發執行交換。

如果worker客戶端在交換結束后直接調用命令，那么slave上命令執行的順序可能與master不同，造成主從數據不一致。

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

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

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

五、生產實踐

從經驗來看，多數redis集群QPS較低但內存用量較大，redis宿主機通常因為達到內存上限觸發擴容，但CPU資源則比較空閑，比如攜程內redis宿主機平均CPU使用率約15%，但平均內存使用率達到50%。

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

成本方面，經驗數據顯示1個ROR實例可容納3個redis實例的數據，因此redis遷ROR能節省2/3的成本。

目前在ROR在生產部署了幾萬個實例。由于海外公有云內存單價高，已基本全部部署為ROR，每年可以節省成本上千萬元。

性能方面，從吞吐量考慮，攜程內部redis集群高QPS占比較低，遠低于ROR的QPS上限（參考上文性能數據）。

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

以下為一個典型redis集群遷移ROR后延遲對比，其中80%為冷數據、20%為熱數據，遷移前后客戶端訪問延遲從200us變為220us左右。

六、項目開源與未來計劃

6.1 項目開源

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

6.2 未來計劃

1）提升單實例QPS

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

2）完善數據結構支持

部分使用頻次較少的數據結構待優化，比如：bitmap目前按照string處理，讀寫放大比較大，待優化性能；stream目前尚未支持，使用內存存儲，待支持。

3）減少全量同步

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