小紅書如何保存視頻無水印，小紅書怎樣保存無水印視頻？

RedKV是小紅書自研的一款基于NVMeSSD的分布式noSQL KV存儲系統(tǒng)，支持無中心和有中心的兩種管控架構，旨在解決公司內實時落盤的KV存儲需求。RedKV1.0基于Gossip協(xié)議做節(jié)點管理，在全公司已經大規(guī)模使用，實時QPS接近1億/秒，存儲量在數(shù)PB級別。RedKV2.0采用中心Shard管理架構，支持全球多云多副本在線彈性伸縮，異地容災和服務秒級切換。

通過分層優(yōu)化，RedKV對比開源同類產品，聚合寫吞吐能力平均提升3倍，讀1.5倍；對標HBase，成本優(yōu)化近40%。RedKV部分兼容Redis協(xié)議，string/hash/zset等主要數(shù)據(jù)類型很好的的支持了公司的絕大部分在線存儲業(yè)務，優(yōu)化了早期Redis集群部署產生的成本問題以及HBase帶來的性能及穩(wěn)定性問題。RedKV和hive數(shù)倉的數(shù)據(jù)互通能力為離線數(shù)據(jù)業(yè)務提供了一種解決方案。

小紅書是年輕人的生活記錄、分享平臺，用戶可以通過短視頻、圖文等形式記錄生活點滴，分享生活方式。在當前的業(yè)務模型下，用戶的畫像數(shù)據(jù)和筆記數(shù)據(jù)用來做風險控制和內容推薦。存儲數(shù)據(jù)具有對象-屬性的特征、維度多，畫像數(shù)據(jù)量已經達到數(shù)十TB， 在線業(yè)務對畫像和筆記數(shù)據(jù)的訪問P99 時延要求非常高。

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

• Redis集群主要適用于緩存場景，開啟AOF數(shù)據(jù)實時落盤對性能有比較大的影響，同時每個節(jié)點需要額外掛載云盤用于存儲AOF。在集群節(jié)點和存儲容量受限的情況下，單節(jié)點的數(shù)據(jù)量設置過大會導致故障后節(jié)點數(shù)據(jù)的failover時間太長，單節(jié)點數(shù)據(jù)量設置小會導致gossip協(xié)議在穩(wěn)定性高要求下節(jié)點個數(shù)受限，同時考慮突發(fā)流量的壓力，Redis集群在部署上需要做一些空間預留，帶來成本高的問題。
• HBase作為一款生態(tài)完善的NoSQL存儲系統(tǒng)，在高QPS下也產生了諸多的性能和穩(wěn)定性問題，如：Zookeeper壓力大時穩(wěn)定性難以保障（節(jié)點探活，服務注冊等都依賴 Zookeeper）；HBase的數(shù)據(jù)文件和WAL日志文件直接寫HDFS，節(jié)點故障后，重放HDFS上的WAL速度慢；Java GC會導致Zookeeper誤殺RegionServer，同時產生毛刺；Major Compaction 會導致I/O飆升，產生長尾效應；受限HDFS的復雜性，黑盒運維對工程師來說比較困難；在小紅書的業(yè)務實戰(zhàn)中，百萬QPS下HBase延時不太理想，核心數(shù)據(jù)用大內存機型兜住，也引發(fā)成本高的問題。

隨著業(yè)務的持續(xù)增長，開源存儲產品已經不能很好的滿足公司的業(yè)務發(fā)展需求, 公司需要一款穩(wěn)定的高性能KV系統(tǒng)支撐內部業(yè)務，一方面要滿足業(yè)務對功能和性能的需求，另一方面要優(yōu)化成本。

2.1. 高QPS和低延時讀取特性

特征數(shù)據(jù)存儲場景：

• 寫入帶寬達到數(shù)十GB/s，要求實時寫入性能和讀取性能都很高。

圖片緩存的場景：

• 數(shù)據(jù)量很大，要求讀取時延低?？梢越邮芄收蠄鼍跋律倭繑?shù)據(jù)丟失。

高性能（P99 < 10ms）：

• 模型數(shù)據(jù)存儲服務。記錄過去一段時間用戶訓練模型數(shù)據(jù)，對P99時延要求非常高，數(shù)據(jù)量在幾十TB。
• 去重存儲服務。數(shù)據(jù)量在幾十TB，P99<10ms, P999<20ms。
• 風控數(shù)據(jù)存儲服務。QPS目前達到千萬級別，P999 < 30ms。

2.2. 低成本的緩存特性

對標Redis：

• 兼容Redis協(xié)議，性能比Redis慢一些，但資源成本降低50%+。

典型場景：

• 廣告的關鍵詞存儲和反作弊業(yè)務，解決大數(shù)據(jù)量、低QPS的存儲模型。

2.3. NoSQL存儲特性

對標HBase：

• 支持數(shù)據(jù)多版本，列存行取等特性，比HBase成本減少30%+，P99時延提升6倍。
• 支持KKV級別的TTL。
• 強一致：目前RedKV1.0采用的主從雙副本，數(shù)據(jù)寫入成功，可以通過配置同步模式來保障2副本寫成功，讀主寫主保障強一致。對于寫性能要求高的場景，可以打開異步寫，寫主成功則返回，依賴增量同步從節(jié)點數(shù)據(jù)。

典型場景：

• 風控服務。實時查詢對P999要求極高，千萬QPS下HBase已經不能滿足性能需求，時延抖動比較大。
• 畫像存儲服務。數(shù)據(jù)的維度多，字段讀取的業(yè)務方多，對時延要求敏感。

RedKV整體架構分3層，接入層兼容Redis協(xié)議，支持各種語言的社區(qū)版SDK和公司定制的中間件版；接入代理層支持千萬QPS的讀寫能力，無狀態(tài)擴展；存儲層提供高可靠讀寫服務。RedKV1.0架構如下圖1，下面我們詳細的展開3層組件的介紹。

圖1. RedKV1.0整體架構

3.1. Client接入層

RedKV集群部署完成后，通過公司內部提供的Service Mesh組件做服務發(fā)現(xiàn)，對Client提供服務。

3.2. Proxy

Proxy層由一個無狀態(tài)CorvusPlus進程組成。它兼容老的Redis Client，擴縮容、升級對無Client和后端集群無感，支持多線程、IO多路復用和端口復用特性。對比開源版本，CorvusPlus增強了自我防護和可觀測特性，實現(xiàn)了可在線配置的功能特性：

• Proxy限流
• 數(shù)據(jù)在線壓縮
• 線程模型優(yōu)化
• backup-read優(yōu)化長尾
• 大key檢測

3.2.1. Proxy限流

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

基于以上問題和目標，對比原生的Redis Cluster模式，RedKV基于令牌桶的流控算法支持了對連接數(shù)、帶寬和QPS多維度限流。在高QPS下，我們的Proxy限流防止了雪崩，如圖2；在大帶寬場景下，我們優(yōu)化了時延，如圖3。

圖2. 雪崩場景下的限流

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

3.2.2. 數(shù)據(jù)在線壓縮

Proxy層本身只做路由轉發(fā)，對CPU的消耗非常低。在大帶寬的場景下，我們可以充分利用Proxy的CPU資源優(yōu)化帶寬和毛刺。在解析Redis協(xié)議時，使用LZ4算法對寫入數(shù)據(jù)進行在線壓縮，讀取時在線解壓。在推薦緩存的使用場景中網絡帶寬和存儲空間壓縮40%以上（如圖4），總體時延并沒有明顯的下降。因為網絡帶寬和寫入讀取數(shù)據(jù)的減少，時延毛刺也變小了。

圖4. Proxy開壓縮后的帶寬優(yōu)化

3.2.3. 線程模型的優(yōu)化

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

3.2.4. backup-read優(yōu)化長尾

在公網環(huán)境下，一個CVM虛擬機和其他多個虛擬機共享一臺物理機。當某個客戶的CVM占用大量資源時，很容易影響到其他CVM的P99時延（由于QOS和隔離性做的不夠好，SMI中斷和內存CE）。在網絡吞吐較大的情況下，某云的DPDK容易被打爆，出現(xiàn)母機OOB。而在RedKV的內部實現(xiàn)中，如果Server請求比較大，某些key的查詢時延比較高的時候，容易產生排隊堆積，或者compaction之后的block cache失效，很容易造成IO長尾。因此，RedKV的P99讀時延的毛刺很難避免，但毛刺是偶爾發(fā)生的，當前我們的主從節(jié)點一定是離散部署在不同的母機上，同時出現(xiàn)P99毛刺的可能很小?；谶@點，我們在Proxy層做了backup read功能，優(yōu)化了RedKV的p99時延問題。

針對以上模型，我們的優(yōu)化思路：

• 檢查節(jié)點的狀態(tài)和過去的延時
• 選擇2個節(jié)點中狀態(tài)好的那個節(jié)點發(fā)送請求
• 計算P99時延，超過P95時延則向另外一個節(jié)點發(fā)送一定數(shù)目的backup read請求數(shù)
• 兩個請求中任意一個請求返回成功則成功，如果超時則繼續(xù)重試

圖5. Backup-read 消峰

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

圖6. Backup-read P999優(yōu)化對比

3.2.5. 大Key檢測

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

3.3. RedKV Cluster

公司的存儲需求場景比較多，如廣告業(yè)務存儲的標簽和數(shù)據(jù)模型很多，同時是非常核心的業(yè)務，業(yè)務需要做資源隔離。為了減少節(jié)點故障縮小數(shù)據(jù)的爆炸半徑 ，這里業(yè)務我們采用無中心管控的架構，即RedKV1.0架構，它能在部署和運維上能大大簡化。無中心的集群架構采用的是Gossip協(xié)議，存儲節(jié)點采用多進程多實例部署，如圖7。

圖7. Gossip管控的KV Cluster

推薦模型訓練的數(shù)據(jù)量非常大，上下游業(yè)務很多，承載的QPS高，對應集群的節(jié)點也比較多，在故障處理和擴縮容方面會觸發(fā)gossip抖動。針對大集群的節(jié)點管理，我們采用有中心管控的架構，即RedKV2.0架構?；赟hard管理的中心架構能更好的支持數(shù)據(jù)遷移和集群擴縮容，存儲節(jié)點采用單進程多實例部署，在多活場景中可以支持副本數(shù)彈性擴展，如圖8。RedKV2.0的相關組件會在后續(xù)的技術文章中詳細介紹。

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

3.3.1. Gossip優(yōu)化

RedKV1.0采用Gossip協(xié)議通信，節(jié)點故障時主從節(jié)點的切換，最長影響時間為30s。一個節(jié)點出現(xiàn)故障時，集群中正常節(jié)點將故障節(jié)點標記為 fail 狀態(tài)需要經過一段收斂時間。在這段時間內，Proxy層有可能將用戶請求轉發(fā)給已經 fail 的節(jié)點，導致請求失敗。減小集群收斂時間能有效減少Proxy層錯誤請求數(shù)量，提高集群的穩(wěn)定性和可用性。

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

• 探測時間優(yōu)化：Redis Gossip協(xié)議正常情況下會每隔100ms隨機選取一個節(jié)點發(fā)送ping包，并更新節(jié)點的ping_sent值為發(fā)送ping包時間。如果集群很大，節(jié)點數(shù)很多，那么故障節(jié)點被ping到的概率就會變小，最多超過node_timeout/2時間給故障節(jié)點發(fā)送ping包。這樣就會導致節(jié)點發(fā)生故障時，集群中正常節(jié)點不能第一時間ping到故障節(jié)點，從而無法立刻感知到故障節(jié)點發(fā)生了故障。為了減少這部分時間，當集群中有節(jié)點超過2s沒有收到故障節(jié)點發(fā)送的pong報文時，就立馬通知其他節(jié)點去ping故障節(jié)點。這樣可以把節(jié)點故障到正常節(jié)點給故障節(jié)點發(fā)送ping的時間控制在2s左右。
• 判定PFAIL時間優(yōu)化：Gossip 協(xié)議現(xiàn)有實現(xiàn)方式是超過node_timeout（通常為15s）時間沒有收到pong報文，就將節(jié)點狀態(tài)置為pfail。本次優(yōu)化將這個時間設置為3s（可配置），如果24小時內（可配置）首次超過3s沒有收到pong報文，就將節(jié)點置為pfail狀態(tài)。如果24小時內頻繁出現(xiàn)，那可能是網絡抖動造成，還走原來的路徑等待node_timeout。
• 減少PFAIL到FAIL的判定時間：只有一個節(jié)點收到集群1/2的節(jié)點的PFAIL信息的時候，才會將故障節(jié)點判定為FAIL狀態(tài)。而PFAIL這個信息是通過Gossip協(xié)議交互的，最久需要1/2 node_timeout才會通知到其他節(jié)點。因此為了加速PFAIL到FAIL的狀態(tài)，所有的節(jié)點按照統(tǒng)一的規(guī)則選出一個種子節(jié)點，PFAIL信息除了隨機發(fā)送一個節(jié)點意外，還會通知這個種子節(jié)點。這樣種子節(jié)點能在最快的時間學習到集群所有節(jié)點的PFAIL信息，從而將故障節(jié)點標記為FAIL狀態(tài)廣播到集群。

3.3.2. RedKV Server

RedKV Server配置多個IO線程同時監(jiān)聽一個端口來接受連接請求，每個線程上的連接數(shù)目會隨機均衡。每個線程只解析自己連接上的請求，并將解析出的報文通過key掛到對應的請求隊列上，每個隊列由一個Worker線程處理。這樣同一個key/同一個slot上的請求都會落到同一根Worker線程上處理，避免了對key進行加鎖，減少鎖沖突和線程切換。Worker線程中會對數(shù)據(jù)進行重編碼，存儲到Rocksdb本地存儲引擎。

RedKV內部的線程模型如下圖9：

圖9. RedKV Server無鎖線程模型

3.3.3. 數(shù)據(jù)存儲

RedKV當前支持的數(shù)據(jù)類型有string、hash和zset，數(shù)據(jù)節(jié)點選擇RocksDB[2]作為本地存儲引擎，集群創(chuàng)建時支持配置多副本，主從節(jié)點離散部署。采用hash打散的方式存儲連續(xù)slot分片的數(shù)據(jù)，能比較好的避免熱點key問題。不同的數(shù)據(jù)類型包含(MetaKey,MetaValue) 和（DataKey, DataValue）,設計格式如下：

MetaKey：

MetaValue：

DataKey：

DataValue：

在如上的編碼方式下，key的設計中保留的slot信息，可以在擴縮容的場景中通過slot靈活的做數(shù)據(jù)遷移。

4.1. 數(shù)據(jù)復制

與傳統(tǒng)解決方案引入同步組件的方式不同，我們快速實現(xiàn)了單向數(shù)據(jù)同步以及集群擴容需求，整體架構去除了對第三方組件的依賴，通過擴展Redis復制協(xié)議實現(xiàn)了RedKV數(shù)據(jù)節(jié)點的直接復制，如圖10。單向復制的限制是擴容需要基于2n做節(jié)點同步，擴容完成后后臺任務根據(jù)3.3.3中定義的key的分片刪除不是本節(jié)點的數(shù)據(jù)。

在多活的部署形態(tài)下，多云集群的一對多的數(shù)據(jù)復制采用單向復制對主集群性能侵入較大，因此我們實現(xiàn)了基于中心管控的數(shù)據(jù)復制策略。該策略支持多個集群的分片異構部署，通過Checkpoint方式定向同步數(shù)據(jù)，不再需要額外的后臺任務去做數(shù)據(jù)淘汰，能很好的支持多對多的多云集群數(shù)據(jù)復制、數(shù)據(jù)破環(huán)和擴縮容。

圖10. RedKV的數(shù)據(jù)復制

4.2. 數(shù)據(jù)批量導入

小紅書大量的離線業(yè)務數(shù)據(jù)存儲在S3 Hive中，每天會有部分數(shù)據(jù)需要增量更新，其他的數(shù)據(jù)會被淘汰。這類場景有幾個挑戰(zhàn)：

• 批量導入：如小紅書的筆記數(shù)據(jù)，一般需要小時級別甚至天級別的更新，所以業(yè)務需要有快捷的批量導入功能。
• 快速更新：特征數(shù)據(jù)的特點就是數(shù)據(jù)量特別大，以筆記為例，全量筆記在TB 級別數(shù)據(jù)量。如果通過 Jedis SDK 寫入，那么存儲集群需要支持百萬QPS的機器資源。當下小紅書數(shù)據(jù)平臺支持業(yè)務把數(shù)據(jù)從hive通過工作流直接導入RedKV，一般是每天凌晨開始寫數(shù)據(jù)，等到晚高峰時大量讀取。這種方法實踐下來，經常導致 RedKV集群的集群內存OOM，影響穩(wěn)定性。
• 性能及穩(wěn)定：數(shù)據(jù)在導入的過程中不能影響讀的性能

實現(xiàn)方案如圖11：

• 自定義獲取集群視圖和數(shù)據(jù)編碼的UDTF，支持RedKV1.0的數(shù)據(jù)格式
• 將原先的抽數(shù)據(jù)，編碼，分片和排序整合成一個HiveOperator，執(zhí)行完成后按指定的OutputFormat輸出SST文件到一個指定S3目錄
• 通過Hadoop distcp工具做數(shù)據(jù)的跨云傳輸，走離線帶寬不影響線上的讀寫業(yè)務
• RedKV集群的節(jié)點SiderCar作為對象存儲的一個Client，RedKV節(jié)點加載本節(jié)點的SST并ingest

圖11. 離線數(shù)據(jù)BulkLoad

4.3. 數(shù)據(jù)批量導出

小紅書的業(yè)務模型訓練數(shù)據(jù)通過Hash存儲在RedKV集群中，業(yè)務下游需要對訓練結果進行離線分析，希望RedKV具有和Hive數(shù)據(jù)流通的能力。RedKV本身是不支持Schema的，如果要將KV數(shù)據(jù)導入Hive表，則需要將Hash的KKV數(shù)據(jù)轉化為一個Table。

RedKV的內部數(shù)據(jù)按hash打散，導入Hive表則需要提供table關鍵字，先按前綴掃描的方式掃描存儲節(jié)點，再生成Hive識別的文件，最后通過Hive Load進行加載。為了更好的兼容其他spark任務，我們選擇Hive支持的標準parquet列式存儲文件，整個I/O鏈路如下圖12：

圖12. RedKV2Hive I/O

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

RedKV中的數(shù)據(jù)采用hmset寫入：

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

通過以上的寫入方式，可以通過配置RedKV2Hive 將KV里面的數(shù)據(jù)導入到Hive里面的Person表 如果單表的數(shù)據(jù)量很大，可以采用分表寫入，比如把person表分成16份

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

4.4. 數(shù)據(jù)的備份和恢復

小紅書的廣告數(shù)據(jù)存儲在自研的分布式KV系統(tǒng)中，數(shù)據(jù)安全主要面臨如下挑戰(zhàn)：

• 基于LSM結構的KV系統(tǒng)，數(shù)據(jù)compaction導致的空間放大會翻倍，數(shù)據(jù)量大后，數(shù)據(jù)備份需要大容量的磁盤
• 單集群故障后，集群恢復的時間不可控
• 備份數(shù)據(jù)依賴第三方系統(tǒng)
• 廣告系統(tǒng)對數(shù)據(jù)的及時恢復能力有比較高的要求，通常要求在分鐘級。為了解決上述幾個問題，我們提出了一種中心管控的主備集群容災策略，通過Proxy接入層的秒級切換能快速切流到一個特定的版本

實現(xiàn)方案如圖13：

• 先部署一個容災集群，主集群對外提供讀寫服務，災備集群保存特定數(shù)量的快照數(shù)據(jù)
• 低峰期，中心管控根據(jù)配置的版本數(shù)和任務時間會定時的向主集群發(fā)送打快照的服務
• 快照完成后通過發(fā)生遠程rsync命令將快照目錄傳送到容災集群，主集群低峰期數(shù)據(jù)壓縮后數(shù)據(jù)量可控，這樣災備集群可以備份指定數(shù)量的版本信息
• 故障發(fā)生后，中心管控可以在災備集群通過RPC指令指定恢復到一個特定的版本
• Proxy接入層通過服務注冊與發(fā)現(xiàn)主鍵配置2組服務，通過動態(tài)的秒級切換可以將流量打向特定版本的集群，完成服務訪問的秒級切換

圖13. 集群備份

4.5. 跨云多活

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

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

• 同機部署，網絡開銷??；
• Sidecar Service 對主服務侵入性??；
• 單獨部署，易于升級

架構靈活，適合日志類存儲系統(tǒng)雙活架構。Redis 以及圖數(shù)據(jù)庫的多云方案都可以改造適用，具體的功能組件和實戰(zhàn)場景會在后續(xù)技術文章詳細介紹。

圖14. 跨云多活架構

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

早期在沒有zprofile中臺的場景下，zprofile用戶和筆記信息都存儲在HBase。為了保證集群的數(shù)據(jù)安全和服務穩(wěn)定性，HBase采用了雙集群部署，寫入和讀取方通過HBase Client API做數(shù)據(jù)存儲。HBase的用戶數(shù)據(jù)在數(shù)十TB，在百萬QPS下，P99時延已經在70ms左右，隨著QPS的快速增長，時延越來越高，集群擴容帶來的存儲成本也越來越高，穩(wěn)定性保障也面臨極大的挑戰(zhàn)。

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

• zprofile-write service 對上游提供統(tǒng)一的數(shù)據(jù)寫入接口服務，提供用戶和比較的Meta管理，用戶數(shù)據(jù)寫入redkv-zprofile-user集群，筆記及其他數(shù)據(jù)寫入redkv-zprofile-other集群。
• zprofile-service對下游提供統(tǒng)一的數(shù)據(jù)消費服務，對應時延要求不高的離線服務，RedKV本身支持單向數(shù)據(jù)復制的能力通過2個offline小集群提供數(shù)據(jù)scan業(yè)務。

整體架構改造完成后，使用RedKV對接同樣QPS的業(yè)務能力，成本節(jié)省了36%, P99性能提升了約5倍。

圖15. zprofile中臺

[1] Pinterest 數(shù)據(jù)復制：

https://medium.com/pinterest-engineering/open-sourcing-rocksplicator-a-real-time-rocksdb-data-replicator-558cd3847a9d

[2] Rocskdb:

https://github.com/facebook/rocksdb/wiki

[3] HeavyKeeper:

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

云哲

小紅書基礎架構存儲組，目前主要負責RedKV1.0架構下的功能開發(fā)和穩(wěn)定性建設，研究方向為分布式KV、持久化內存KV存儲和表格存儲。

久美

小紅書基礎架構存儲組，目前主要負責RedKV2.0架構下的功能開發(fā)和存儲中間件建設，研究研究方向為分布式KV和存儲中間件。

文書

小紅書基礎架構存儲組，目前主要負責RedKV1.0架構下的功能開發(fā)和跨云多活建設，研究方向為分布式KV和存儲中間件。

來源:微信公眾號:小紅書技術REDtech

出處:https://mp.weixin.qq.com/s/ES9cFTJxw058Ktb66NmKYA

版權聲明：本文內容由互聯(lián)網用戶自發(fā)貢獻，該文觀點僅代表作者本人。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。如發(fā)現(xiàn)本站有涉嫌抄襲侵權/違法違規(guī)的內容， 請發(fā)送郵件至 sumchina520@foxmail.com 舉報，一經查實，本站將立刻刪除。