小紅書自研KV儲存架構如何實現萬億量級儲存與跨雲多活

1

小紅書是年輕人的生活記錄、分享平臺，使用者可以透過短影片、圖文等形式記錄生活點滴，分享生活方式。在當前的業務模型下，使用者的畫像資料和筆記資料用來做風險控制和內容推薦。儲存資料具有物件-屬性的特徵、維度多，畫像資料量已經達到數十TB， 線上業務對畫像和筆記資料的訪問P99 時延要求非常高。

2020年之前公司選擇的NoSQL儲存產品主要有：Redis、HBase，隨著公司DAU的高速增長，早期的儲存方案遇到如下挑戰：

隨著業務的持續增長，開源儲存產品已經不能很好的滿足公司的業務發展需求, 公司需要一款穩定的高效能KV系統支撐內部業務，一方面要滿足業務對功能和效能的需求，另一方面要最佳化成本。

2

特徵資料儲存場景：

圖片快取的場景：

高效能（P99 < 10ms）：

對標Redis：

典型場景：

對標HBase：

典型場景：

3

RedKV整體架構分3層，接入層相容Redis協議，支援各種語言的社群版SDK和公司定製的中介軟體版；接入代理層支援千萬QPS的讀寫能力，無狀態擴充套件；儲存層提供高可靠讀寫服務。RedKV1.0架構如下圖1，下面我們詳細的展開3層元件的介紹。

圖1. RedKV1.0整體架構

RedKV叢集部署完成後，透過公司內部提供的Service Mesh元件做服務發現，對Client提供服務。

Proxy層由一個無狀態CorvusPlus程式組成。它相容老的Redis Client，擴縮容、升級對無Client和後端叢集無感，支援多執行緒、IO多路複用和埠複用特性。對比開源版本，CorvusPlus增強了自我防護和可觀測特性，實現了可線上配置的功能特性：

小紅書當前的業務模型比較多，客戶端行為無法預期，可能出現的發版錯誤、系統問題及網路抖動引發客戶端重試，突發的qps會影響服務穩定性。在高QPS壓力下，Proxy處理客戶端讀寫超時，大量重試會導致雪崩，業務高峰期單個 Proxy 頻寬可能超過機器的出入頻寬限制，而儲存叢集只能保證在有限的資源內提供穩定可靠的服務。針對這類場景，我們需要保證流量過載時，Proxy和RedKV服務不被打崩，能保障高可用。

基於以上問題和目標，對比原生的Redis Cluster模式，RedKV基於令牌桶的流控演算法支援了對連線數、頻寬和QPS多維度限流。在高QPS下，我們的Proxy限流防止了雪崩，如圖2；在大頻寬場景下，我們最佳化了時延，如圖3。

圖2. 雪崩場景下的限流

圖3. 大頻寬場景下的限流

Proxy層本身只做路由轉發，對CPU的消耗非常低。在大頻寬的場景下，我們可以充分利用Proxy的CPU資源最佳化頻寬和毛刺。在解析Redis協議時，使用LZ4演算法對寫入資料進行線上壓縮，讀取時線上解壓。在推薦快取的使用場景中網路頻寬和儲存空間壓縮40%以上（如圖4），總體時延並沒有明顯的下降。因為網路頻寬和寫入讀取資料的減少，時延毛刺也變小了。

圖4. Proxy開壓縮後的頻寬最佳化

Proxy採用IO多路複用技術，每個連線維護一個請求處理佇列和響應佇列，保序的返回給客戶端。Proxy在收到RedKV Server的回應之後，如果沒有收到所有傳送的cmd的返回，則會一直等待所有cmd的返回後再傳送給client，對於讀的場景這種模式非常不友好。經過改造，如果某個cmd之前的cmd都已經正常響應，則可以馬上響應給client，不需要再等後面的所有cmd請求完成。

在公網環境下，一個CVM虛擬機器和其他多個虛擬機器共享一臺物理機。當某個客戶的CVM佔用大量資源時，很容易影響到其他CVM的P99時延（由於QOS和隔離性做的不夠好，SMI中斷和記憶體CE）。在網路吞吐較大的情況下，某雲的DPDK容易被打爆，出現母機OOB。而在RedKV的內部實現中，如果Server請求比較大，某些key的查詢時延比較高的時候，容易產生排隊堆積，或者compaction之後的block cache失效，很容易造成IO長尾。因此，RedKV的P99讀時延的毛刺很難避免，但毛刺是偶爾發生的，當前我們的主從節點一定是離散部署在不同的母機上，同時出現P99毛刺的可能很小。基於這點，我們在Proxy層做了backup read功能，最佳化了RedKV的p99時延問題。

針對以上模型，我們的最佳化思路：

圖5. Backup-read 消峰

因為backup read轉發不需要複製記憶體，透過索引來保證生命週期，而且只有超過P95時延的報文會被檢查是否能傳送backup read，因此，只要5%的報文會傳送兩次，對叢集基本不會增加壓力。圖6為一個叢集中 P999從35ms降低到4ms左右，效果非常明顯。對比HBase同樣的業務場景，客戶端在同樣的timeout的配置下，我們的方案提高了客戶端的成功率。

圖6. Backup-read P999最佳化對比

我們線上很多叢集在業務使用過程中會偶發的產生一些毛刺，透過抓包發現，這裡毛刺有很大一部分原因是因為大Key造成的。為了甄別這類問題，我們在Proxy層支援的大Key的可觀測指標。Proxy在解析Redis的cmd可以附帶統計KV的大小。對於string讀型別的command，讀到的val值大於 big-string-size 判定為大key；對於寫型別的command， 請求值大於 big-string-size 判定為大key；對於hash/zset則為一次讀取的kv總數大小。透過增加read_size（所有讀請求總共讀到的位元組數） 和 write_size （所有寫請求總共寫入的位元組數）監控，rate(read_size) / rate(total_req_amount) 可以計算出平均請求值大小。大Key和熱Key是KV系統不可避免的2個場景，針對大Key，我們提供了Proxy層的資料壓縮能力；對於熱Key， 我們在Server層基於HeavyKeeper^[3]演算法做了topK統計和處理。

公司的儲存需求場景比較多，如廣告業務儲存的標籤和資料模型很多，同時是非常核心的業務，業務需要做資源隔離。為了減少節點故障縮小資料的爆炸半徑 ，這裡業務我們採用無中心管控的架構，即RedKV1.0架構，它能在部署和運維上能大大簡化。無中心的叢集架構採用的是Gossip協議，儲存節點採用多程式多例項部署，如圖7。

圖7. Gossip管控的KV Cluster

推薦模型訓練的資料量非常大，上下游業務很多，承載的QPS高，對應叢集的節點也比較多，在故障處理和擴縮容方面會觸發gossip抖動。針對大叢集的節點管理，我們採用有中心管控的架構，即RedKV2.0架構。基於Shard管理的中心架構能更好的支援資料遷移和叢集擴縮容，儲存節點採用單程式多例項部署，在多活場景中可以支援副本數彈性擴充套件，如圖8。RedKV2.0的相關元件會在後續的技術文章中詳細介紹。

圖8. 基於中心管控的KV Cluster

RedKV1.0採用Gossip協議通訊，節點故障時主從節點的切換，最長影響時間為30s。一個節點出現故障時，叢集中正常節點將故障節點標記為 fail 狀態需要經過一段收斂時間。在這段時間內，Proxy層有可能將使用者請求轉發給已經 fail 的節點，導致請求失敗。減小叢集收斂時間能有效減少Proxy層錯誤請求數量，提高叢集的穩定性和可用性。

RedKV1.0透過如下三個步驟加快檢視收斂：

RedKV Server配置多個IO執行緒同時監聽一個埠來接受連線請求，每個執行緒上的連線數目會隨機均衡。每個執行緒只解析自己連線上的請求，並將解析出的報文透過key掛到對應的請求佇列上，每個佇列由一個Worker執行緒處理。這樣同一個key/同一個slot上的請求都會落到同一根Worker執行緒上處理，避免了對key進行加鎖，減少鎖衝突和執行緒切換。Worker執行緒中會對資料進行重編碼，儲存到Rocksdb本地儲存引擎。

RedKV內部的執行緒模型如下圖9：

圖9. RedKV Server無鎖執行緒模型

RedKV當前支援的資料型別有string、hash和zset，資料節點選擇RocksDB^[2]作為本地儲存引擎，叢集建立時支援配置多副本，主從節點離散部署。採用hash打散的方式儲存連續slot分片的資料，能比較好的避免熱點key問題。不同的資料型別包含(MetaKey,MetaValue) 和（DataKey, DataValue）,設計格式如下：

MetaKey：

MetaValue：

DataKey：

DataValue：

在如上的編碼方式下，key的設計中保留的slot資訊，可以在擴縮容的場景中透過slot靈活的做資料遷移。

4

與傳統解決方案引入同步元件的方式不同，我們快速實現了單向資料同步以及叢集擴容需求，整體架構去除了對第三方元件的依賴，透過擴充套件Redis複製協議實現了RedKV資料節點的直接複製，如圖10。單向複製的限制是擴容需要基於2ⁿ做節點同步，擴容完成後後臺任務根據3.3.3中定義的key的分片刪除不是本節點的資料。 

在多活的部署形態下，多雲叢集的一對多的資料複製採用單向複製對主叢集效能侵入較大，因此我們實現了基於中心管控的資料複製策略。該策略支援多個叢集的分片異構部署，透過Checkpoint方式定向同步資料，不再需要額外的後臺任務去做資料淘汰，能很好的支援多對多的多雲叢集資料複製、資料破環和擴縮容。

圖10. RedKV的資料複製

小紅書大量的離線業務資料儲存在S3 Hive中，每天會有部分資料需要增量更新，其他的資料會被淘汰。這類場景有幾個挑戰：

實現方案如圖11：

圖11. 離線資料BulkLoad

小紅書的業務模型訓練資料透過Hash儲存在RedKV叢集中，業務下游需要對訓練結果進行離線分析，希望RedKV具有和Hive資料流通的能力。RedKV本身是不支援Schema的，如果要將KV資料匯入Hive表，則需要將Hash的KKV資料轉化為一個Table。

RedKV的內部資料按hash打散，匯入Hive表則需要提供table關鍵字，先按字首掃描的方式掃描儲存節點，再生成Hive識別的檔案，最後透過Hive Load進行載入。為了更好的相容其他spark任務，我們選擇Hive支援的標準parquet列式儲存檔案，整個I/O鏈路如下圖12：

圖12. RedKV2Hive I/O

示例：RedKV裡面的Key 寫入規定以 {tablename}_ 開始，比如一個artical表

RedKV中的資料採用hmset寫入：

hmset {person}_1 name John quantity 20 price 200.23hmset {person}_2 name Henry quantity 30 price 3000.45

透過以上的寫入方式，可以透過配置RedKV2Hive 將KV裡面的資料匯入到Hive裡面的Person表 如果單表的資料量很大，可以採用分表寫入，比如把person表分成16份

hmset {person:1}_1 name John quantity 20 price 200.23hmset {person:1}_2 name Henry quantity 30 price 3000.45...hmset {person:16}_100000 name Tom quantity 43 price 234.56

小紅書的廣告資料儲存在自研的分散式KV系統中，資料安全主要面臨如下挑戰：

實現方案如圖13：

圖13. 叢集備份

為了應對高速增長的業務需求，公司對雲廠商的服務穩定性要求越來越高，單機房雲服務難以滿足公司穩定性的需求，跨雲多活可以提高服務的穩定性，雙寫雙讀可以實現主備資料中心均對外提供讀寫服務, 這樣既不會造成資料中心的資源浪費又可以實現跨地域容災。我們對業界常用的方案做了一些對比分析：

我們綜合調研其他廠商的架構經驗，提出了RedKV雙活設計( Replicator as Sidecar Service同機部署) 方案，如圖14。

架構靈活，適合日誌類儲存系統雙活架構。Redis 以及圖資料庫的多雲方案都可以改造適用，具體的功能元件和實戰場景會在後續技術文章詳細介紹。

圖14. 跨雲多活架構

5

正如第2節描述的小紅書業務需求場景，本節透過一個典型的業務場景來展示RedKV在noSQL儲存下的收益。

早期在沒有zprofile中臺的場景下，zprofile使用者和筆記資訊都儲存在HBase。為了保證叢集的資料安全和服務穩定性，HBase採用了雙叢集部署，寫入和讀取方透過HBase Client API做資料儲存。HBase的使用者資料在數十TB，在百萬QPS下，P99時延已經在70ms左右，隨著QPS的快速增長，時延越來越高，叢集擴容帶來的儲存成本也越來越高，穩定性保障也面臨極大的挑戰。

RedKV1.0上線後，經過半年多的打磨，開始慢慢承接公司的核心業務。推薦平臺架構組也開始著手打造zprofile中臺服務，收斂上下游的業務，提供標準統一的讀寫方式。在儲存方案上，平臺架構組同學和儲存組經過多次的業務溝通，最終選擇使用RedKV作為底層儲存，主要對接兩類業務方：分別是資料生產者 producer 以及資料消費方 consumer。zprofile最終的中臺架構如下圖15：

整體架構改造完成後，使用RedKV對接同樣QPS的業務能力，成本節省了36%, P99效能提升了約5倍。

圖15. zprofile中臺

6

[1] Pinterest 資料複製：

[2] Rocskdb: 

[3] HeavyKeeper:

 HeavyKeeper: An Accurate Algorithm for Finding Top-k Elephant Flows | USENIX