俄羅斯：將審查iPhone等外國公司設備 保數據安全
iPhone和特斯拉都屬于在各自領域領頭羊的品牌，推出的產品也也都是數一數二的，但對于一些國家而言，它們的產品可靠性和安全性還是在限制范圍內。近日，俄羅斯聯邦通信、信息技術
作者簡介
patpatbear，攜程軟件技術專家，負責攜程緩存內核的維護，熱愛開源，專注于高性能、分布式NoSQL系統的建設和應用。
redis使用內存作為存儲介質，具有良好的性能和低延遲，但其內存容量通常成為瓶頸，且內存價格較高，導致redis使用成本較高。
隨著SSD磁盤性能的不斷提高，NVMe SSD的隨機讀寫延遲也僅有幾十微秒，與redis的固有延遲（100~200us）相當，用SSD作為存儲介質也可以達到較低的延遲，同時節省成本。
因此我們研發了ROR(Redis-On-Rocks)產品，通過對redis內核增強以支持數據冷熱交換，使用磁盤擴展緩存容量，可節省約2/3成本，而性能也能滿足大多數業務需求。
ROR核心思路很簡單：在redis codebase基礎上擴展冷熱交換功能，實現redis數據冷熱多級存儲，降低緩存的綜合使用成本。
ROR將數據分為冷熱兩部分：
ROR負責冷熱數據的交換：
由于ROR繼承了redis的數據結構和命令實現，只負責冷熱數據交換，因此可以兼容幾乎所有的redis命令，可快速跟進redis官方新特性。
從長遠發展考慮，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%計算
因此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 | RoF | |
HGET | 100thd | QPS=22134 LAT(mean,p99)=4762 27495(us) | QPS=10195 Latency(mean,p99): 9730 16521(us) |
1wqps | QPS=9968 LAT(mean,p99)=343 969(us) | QPS=9956 Latency(mean,p99): 14270 100746(us) | |
HSET | 100thd | QPS=26182 Latency(mean,p99): 4034 21802(us) | QPS=7994 |
1wqps | QPS=9969 Latency(mean,p99): 511 4437(us) | QPS=7806 | |
測試說明：
對于超大的聚合key，RoF將整個key加載到內存中，會有明顯的延遲尖刺（可達秒級）；而ROR只將必要的subkey換入內存，則不會有明顯的延遲尖刺。
多數使用redis的業務對延遲比較敏感，不能接受過大延遲尖刺。
場景/方案 | ROR | RoF |
HGET hugehash field | <1ms | 1.48s |
LPOP hugelist | <1ms | 0.704s |
測試說明：
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
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的設計如下：
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有區別：
冷數據（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考慮提供可用性與一致性的選項，允許少量數據不一致的情況下增量同步。
本文鏈接：http://www.www897cc.com/showinfo-26-27977-0.html開源 | 攜程 Redis On Rocks 實踐，節省 2/3 Redis成本
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： C++中的低級內存操作
下一篇： 解析Java中的跨域請求問題與解決方案
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號