性能超前，詳解騰訊云新一代Redis緩存數(shù)據(jù)庫

　　背景

　　當(dāng)前內(nèi)存數(shù)據(jù)庫發(fā)展迅速，用戶對于存儲系統(tǒng)的要求也越來越高，為了滿足各類業(yè)務(wù)場景的需要，騰訊云設(shè)計了新一代的內(nèi)存數(shù)據(jù)庫，不但保留了原來系統(tǒng)的高性能，高可用等特性，同時還兼容了當(dāng)前流行的Redis原生協(xié)議及使用方式。我們試圖在解決原生方案短板的基礎(chǔ)上，不斷創(chuàng)新，使得新系統(tǒng)同時具備易懂、易用、易維護(hù)、高可靠、低成本等特點。主要體現(xiàn)在以下幾個方面：

　　1.沿用了上一代自研系統(tǒng)使用共享內(nèi)存的數(shù)據(jù)存儲方案，避免Redis采用AOF機(jī)制，恢復(fù)時間過久的問題，極大的降低了在升級、進(jìn)程異常等場景產(chǎn)生的影響。同時，使用全新的快照與流水機(jī)制，解決了Fork機(jī)制造成的內(nèi)存預(yù)留問題

　　2. 在存儲引擎方面，對于自研及開源方案進(jìn)行重新分析整理，進(jìn)行了再次創(chuàng)新，不但使用多規(guī)格Block靈活組合的存儲方式，內(nèi)部數(shù)據(jù)結(jié)構(gòu)同樣采用動態(tài)頁管理，對比原生引擎，極大的提高了內(nèi)存使用率的同時，也降低了運行過程中產(chǎn)生內(nèi)存碎片的機(jī)率

　　3. 單進(jìn)程多線程的模型讓運維部署更加簡便，同時精簡模塊數(shù)量，讓請求路徑更短

　　4.更加精細(xì)化的數(shù)據(jù)管理，實現(xiàn)快速的過期淘汰及精確的LRU特性

　　5.實現(xiàn)了強(qiáng)一致特性，滿足了金融等業(yè)務(wù)對于數(shù)據(jù)一致性的強(qiáng)需求

　　6. 集群版模式中，支持了多數(shù)據(jù)庫的場景，降低用戶由主從版遷移至集群版的使用門檻

　　7.存儲節(jié)點可直接轉(zhuǎn)發(fā)用戶請求，降低后臺數(shù)據(jù)變更對于客戶端的依賴，原生主從版客戶端可直接訪問集群版，無需修改代碼

　　8.我們正在兼容更多的原生數(shù)據(jù)庫協(xié)議，讓更多的用戶可以無縫切換，體驗更多的新特性

　　技術(shù)架構(gòu)優(yōu)化歷程

　　在架構(gòu)方面我們將當(dāng)前比較流行的兩層(不包含客戶端)結(jié)構(gòu)簡化成了單層，如下圖所示。

　　圖1 架構(gòu)圖

　　圖中的Master為集群的管理節(jié)點，每組Master管理一個地域的若干集群。

　　Cache則是實際的數(shù)據(jù)存儲節(jié)點。架構(gòu)中不再顯式設(shè)置接入層，而是通過Cache轉(zhuǎn)發(fā)用戶請求，這樣做的好處：

　　單純的存儲或接入模塊，由于對不同資源類型(CPU、網(wǎng)卡、內(nèi)存等)需求的傾斜，無法很好的提高當(dāng)前高配機(jī)型的設(shè)備利用率。也基于這個原因，理論上合并后的單層結(jié)構(gòu)能更好的利用硬件資源，節(jié)約成本減少模塊數(shù)量可以減少大量運維操作，便于運維同學(xué)部署及規(guī)劃資源等路由更接近數(shù)據(jù)，因此在某臺Cache上進(jìn)行數(shù)據(jù)遷移動作時，可以更加實時的對用戶請求做出應(yīng)對(轉(zhuǎn)發(fā)至最新的目標(biāo))，減少變更對用戶請求的影響

　　針對一些對于接入層有強(qiáng)需求的場景，比如，某業(yè)務(wù)的客戶端鏈接數(shù)極多，我們也有針對性的做了優(yōu)化。Cache可退化為純接入機(jī)使用，這樣可以方便的擴(kuò)展為兩層結(jié)構(gòu)，統(tǒng)一使用一套代碼，無需單獨維護(hù)。

　　數(shù)據(jù)分布方面，采用了全部打散的方式，即在任意一臺Cache上既有主數(shù)據(jù)也有(其他業(yè)務(wù))備份數(shù)據(jù)，完全以Shard為粒度(物理內(nèi)存單元)進(jìn)行管理，如下圖所示。

　　圖2 Shard分布

　　每臺Cache的內(nèi)存被劃分為若干Shard，無論是主從版還是集群版，用戶的主或備數(shù)據(jù)可能落到任意Cache，分配策略支持跨機(jī)架、跨機(jī)房等。這樣做的目的有：

　　不再有單純的熱備設(shè)備，減少低負(fù)載設(shè)備比例，充分利用整個集群的網(wǎng)卡、CPU等資源當(dāng)一個或若干節(jié)點異常時，利用整個集群的能力進(jìn)行容錯(切換流量)與恢復(fù)(在不同節(jié)點重建備份)，避免雪球效應(yīng)在分配時，將考慮現(xiàn)有設(shè)備主備Shard比例及負(fù)載，優(yōu)化裝箱算法，可是集群資源更加均衡

　　由于CKV+兼容Redis協(xié)議及各種使用場景，因此也區(qū)分了主從版與集群版。對于集群版來說，經(jīng)過對比，數(shù)據(jù)哈希仍然采用了Pre-sharding的方式，如下圖所示。

　　圖3數(shù)據(jù)哈希

　　對于單個Shard來說，最大可管理內(nèi)存為8T，由于目前設(shè)備限制，實際最大可支持512G，因此集群版支持的容量范圍為 [1G，512G] * 16384 = [16T，8P]。當(dāng)然在實際應(yīng)用中，還需考慮系統(tǒng)內(nèi)部預(yù)留資源等因素，且Shard大小及Slot對應(yīng)關(guān)系的規(guī)劃也要視物理資源情況而定。

　　內(nèi)存引擎設(shè)計，確定CKV+引擎

　　內(nèi)存管理是內(nèi)存數(shù)據(jù)庫系統(tǒng)中非常重要的一環(huán)，在CKV+系統(tǒng)的設(shè)計階段，對于引擎也是進(jìn)行了大量的討論與調(diào)研，根據(jù)我們的經(jīng)驗，同時吸納了多種主流內(nèi)存管理體系的優(yōu)點，確定了當(dāng)前CKV+的引擎方案。主要特點歸納如下：

　　使用共享內(nèi)存，方便升級或進(jìn)程異常時快速恢復(fù)基于共享內(nèi)存實現(xiàn)了紅黑樹算法，在保證性能的前提下，兼容Redis中的Hash、Set、ZSet數(shù)據(jù)類型使用多規(guī)格Block作為(最小的)數(shù)據(jù)存儲單位，更加靈活同時內(nèi)存空隙更小使用經(jīng)典的Page管理模式，優(yōu)化了動態(tài)分配策略，提高了Page回收幾率，降低內(nèi)存碎片率用戶數(shù)據(jù)所依附的內(nèi)部數(shù)據(jù)結(jié)構(gòu)同樣基于Page進(jìn)行動態(tài)分配，減少內(nèi)部預(yù)留空間的浪費

　　圖4 內(nèi)存引擎

　　內(nèi)存引擎的一個重要指標(biāo)就是內(nèi)存使用率，我們與原生Redis存儲進(jìn)行了對比測試。

　　測試方法：使用同樣的隨機(jī)數(shù)據(jù)，分別寫入Redis及CKV+的1G實例，對比實際存儲數(shù)據(jù)量的多少。

　　樣本大�。簁ey [10，30]，Value [20，100]

　　圖5 使用率對比

　　測試結(jié)果顯示，在簡單String類型的場景下，兩者存儲量近似，但在稍復(fù)雜的結(jié)構(gòu)中，CKV+則可以存儲更多的用戶數(shù)據(jù)。

　　大膽嘗試，采用單進(jìn)程多線程模型

　　對于內(nèi)存數(shù)據(jù)庫來說，高性能仍然是大前提，而開發(fā)過程中使用的線程模型及框架對于這個層面影響較大。因此在設(shè)計初始，我們對于這部分也做了大膽嘗試。

　　首先，我們使用了單進(jìn)程多線程的模式，而非大多開源系統(tǒng)的單進(jìn)程單線程的路數(shù)，一方面可以更好的利用整機(jī)資源，另一方面也能降低運維門檻。對于多線程來說，需要解決的主要問題有如下幾點：

　　若干線程共同管理內(nèi)存則勢必需要引入鎖，而高配機(jī)型核數(shù)多、線程多，加鎖可能帶來毛刺單個進(jìn)程需要管理多個業(yè)務(wù)數(shù)據(jù)，特別是主從版，每塊內(nèi)存Shard容量較大，難免有比較龐大的kv數(shù)據(jù)，同時主從版支持部分耗時操作，需要盡量減少實例間的相互影響線程間通信或共享數(shù)據(jù)的代價要小，比如同步路由信息等同時要考慮諸如線程上下文切換、CPU緩存命中率、IO等因素

　　在進(jìn)行了一系列的調(diào)研工作后，最終確定線程模型為：每個物理核啟動一個線程，管理若干內(nèi)存Shard，如下圖所示。

　　圖6 線程模型

　　使用這種模式的主要考慮：

　　具體內(nèi)存的操作僅由某一個CPU處理，避免加鎖，某個Shard出現(xiàn)熱點時，對其他線程管理的實例影響較小在管理實例數(shù)量不多的情況下，空閑CPU可以處理網(wǎng)絡(luò)及磁盤IO，以及請求的編解碼等工作，提高整機(jī)資源利用率線程間不存在依賴或競爭關(guān)系，避免不必要的損耗 性能測試

　　性能應(yīng)該是大家比較關(guān)注的部分，我們針對Redis的String與ZSet兩種數(shù)據(jù)結(jié)構(gòu)進(jìn)行了性能測試，結(jié)果如下。

　　注：

　　"單實例"表示一臺Cache僅管理1個Shard，"N實例"則表示同時管理N個Shard所有測試均使用2400個客戶端對整臺設(shè)備進(jìn)行壓測測試不涉及消息轉(zhuǎn)發(fā)，即客戶端直接請求數(shù)據(jù)所在設(shè)備測試樣本分別使用10Byte與100Byte的數(shù)據(jù)本次測試并未啟用DPDK，后續(xù)會進(jìn)行補(bǔ)充

　　圖7 STRING類型讀寫性能對比

　　圖8 ZSET類型讀寫性能對比

　　結(jié)語

　　騰訊云新一代內(nèi)存數(shù)據(jù)庫不但全面兼容了Redis的數(shù)據(jù)結(jié)構(gòu)及使用方法，同時解決了原生方案在備份、容災(zāi)等方面的不足。在性能方面，我們并沒有滿足于現(xiàn)狀，后續(xù)還將更細(xì)致的優(yōu)化邏輯流程，并引入DPDK等特性，進(jìn)一步提升系統(tǒng)性能。成本也是我們關(guān)注的重點，當(dāng)前的系統(tǒng)架構(gòu)與線程模型能更好的適應(yīng)不斷提升的硬件設(shè)備性能，提高硬件資源的利用率，同時，我們也將引進(jìn)冷熱數(shù)據(jù)分離等技術(shù)，在保證性能的前提下，更好的為用戶節(jié)省成本。

　　作者 ： carloszhao，2010年加入騰訊，前后參與過分布式計算、存儲等多個項目的設(shè)計與開發(fā)，目前在騰訊TEG-基礎(chǔ)架構(gòu)部，負(fù)責(zé)內(nèi)存數(shù)據(jù)庫的研發(fā)工作。