作者介紹

京東零售在線存儲部，致力于分布式系統(tǒng)、開源數(shù)據(jù)庫技術(shù)的研究，主要負(fù)責(zé)數(shù)據(jù)庫性能調(diào)優(yōu)、監(jiān)控和架構(gòu)設(shè)計。

過去十年，隨著移動互聯(lián)網(wǎng)指數(shù)級的增長，企業(yè)和用戶對應(yīng)用程序的響應(yīng)性能要求越來越高， 如何在完美應(yīng)對海量用戶規(guī)模和海量數(shù)據(jù)的同時保證優(yōu)秀的產(chǎn)品體驗(yàn)，是數(shù)據(jù)庫面臨的挑戰(zhàn)。無論是機(jī)械硬盤還是SSD存儲介質(zhì)，企業(yè)都需要緩存技術(shù)加速數(shù)據(jù)的訪問、支撐高并發(fā)和大吞吐，通過引入分布式緩存方案，提升應(yīng)用程序性能，消除數(shù)據(jù)庫熱點(diǎn)。

但是，緩存技術(shù)的引入增加了業(yè)務(wù)架構(gòu)的復(fù)雜度，降低了開發(fā)效率，同時還面臨著緩存一致性、擊穿、雪崩等挑戰(zhàn)。因此，我們基于線上運(yùn)營多年的KV存儲引擎JIMDB，重新打造了JIMKV分布式數(shù)據(jù)庫，融合緩存與存儲的統(tǒng)一架構(gòu)，解決了緩存難題，幫助研發(fā)人員聚焦業(yè)務(wù)邏輯，降低硬件成本，提升生產(chǎn)效率。

一、早期架構(gòu)及功能實(shí)現(xiàn)

早期，我們主要使用基于Redis客戶端集群方案自研的JIMDB來加速業(yè)務(wù)的訪問，主要解決了自動故障檢測恢復(fù)、自動彈性調(diào)度等問題。架構(gòu)圖如下：

1、自動故障檢測恢復(fù)

在故障檢測和故障切換的方案中，比較容易想到的就是引入Zookeeper。通過Zookeeper的臨時節(jié)點(diǎn)探測不存活的服務(wù)，但是由于服務(wù)端代碼需要修改、跨機(jī)房部署不方便、watch數(shù)目和連接數(shù)過多存在性能問題等原因，這個方案最終沒有被采用。

于是我們決定自己寫探測程序，這個探測程序主要是檢測JIMDB實(shí)例的存活狀態(tài)，但是它需要盡可能地解決由于部分網(wǎng)絡(luò)不通時導(dǎo)致的誤判問題。采用的方案是，對探測程序部署多個，每個部署在機(jī)房的不同機(jī)架下。多個探測實(shí)例同時對同一個JIMDB實(shí)例進(jìn)行探測，只要有一個探測實(shí)例檢測到服務(wù)端實(shí)例是存活的，那么該實(shí)例就被認(rèn)為是存活狀態(tài)；當(dāng)沒有人反饋其為存活狀態(tài)，且超過半數(shù)的探測實(shí)例認(rèn)為該實(shí)例死亡時，則通知故障恢復(fù)程序進(jìn)行主從切換，變更集群拓?fù)浣Y(jié)構(gòu)，并把新的拓?fù)浣Y(jié)構(gòu)通知給所有的客戶端。由此，故障檢測和恢復(fù)的問題基本算是解決了。

2、自動彈性調(diào)度

業(yè)務(wù)流量突然飆升，容量不足等問題都需要運(yùn)維通過管理工具進(jìn)行擴(kuò)容增加實(shí)例數(shù)，另外也有一部分業(yè)務(wù)申請了集群空間。由于業(yè)務(wù)調(diào)整等原因，訪問量變小了或者停用了，平臺管理人員比較難發(fā)現(xiàn)。為了提高平臺自動化的能力，減少運(yùn)維人員的工作量，需要讓平臺動起來，所以彈性伸縮的需求擺在了開發(fā)人員的面前。

為了讓平臺彈性伸縮起來，需要對集群的各項(xiàng)指標(biāo)進(jìn)行監(jiān)控，比如對OPS、內(nèi)存使用率、網(wǎng)絡(luò)流量等進(jìn)行監(jiān)控，統(tǒng)計這些指標(biāo)一段時間內(nèi)是否達(dá)到了設(shè)置的閾值，當(dāng)超過擴(kuò)容的閾值時自動觸發(fā)擴(kuò)容，當(dāng)?shù)陀诳s容的閾值時自動進(jìn)行縮容釋放資源。

縮容的過程和擴(kuò)容的過程基本一致，擴(kuò)容是把一個實(shí)例上的部分slot遷移到新的實(shí)例上，縮容是把一個shard實(shí)例上的所有slot遷移到另一個實(shí)例上進(jìn)行合并。

擴(kuò)容時由于需要增加實(shí)例，增加的實(shí)例應(yīng)該部署在哪臺機(jī)器上才合適呢？為了選擇出最優(yōu)的機(jī)器，有一個采集程序會定期進(jìn)行信息收集，然后根據(jù)CPU繁忙情況、網(wǎng)絡(luò)流量、OPS、內(nèi)存剩余空間、機(jī)器上的實(shí)例數(shù)等進(jìn)行綜合打分，各項(xiàng)指標(biāo)都比較空閑的得高分，如果有一項(xiàng)指標(biāo)不符合部署要求則直接淘汰，然后再從得分高的機(jī)器中選擇一臺機(jī)器進(jìn)行部署。

由于擴(kuò)容在集群中是并發(fā)進(jìn)行的，因此有可能多個處理線程會同時把實(shí)例部署到同一臺物理機(jī)上，當(dāng)大家部署完成后可能實(shí)例數(shù)等指標(biāo)就不符合要求了。因此需要有一個預(yù)分配資源的計算，對未使用的資源進(jìn)行預(yù)占并被計算在內(nèi)，如果部署失敗就需要把這些資源值做相應(yīng)的扣除，避免并發(fā)部署出現(xiàn)使用資源超限的情況。對同一個集群還需要控制每臺物理機(jī)上最大可部署的實(shí)例數(shù)，避免同一個物理機(jī)部署實(shí)例數(shù)過多，導(dǎo)致機(jī)器故障時對同一個集群影響過大。為了防止同一個機(jī)房路由器故障或者斷電等情況的出現(xiàn)，同一個shard的主從實(shí)例應(yīng)該跨機(jī)架，對有跨機(jī)房需求的應(yīng)用，同一個shard的主從實(shí)例還應(yīng)該部署在不同的機(jī)房。

二、大促挑戰(zhàn)及行業(yè)發(fā)展趨勢

隨著近些年京東618、雙11大促的火熱，業(yè)務(wù)增長遠(yuǎn)超預(yù)期，資源緊缺成為一種常態(tài)。雖然JIMDB在性能方案滿足了當(dāng)前的業(yè)務(wù)需求，但是服務(wù)器內(nèi)存成本壓力與日俱增，所有業(yè)務(wù)數(shù)據(jù)全放內(nèi)存太浪費(fèi)，某些業(yè)務(wù)對數(shù)據(jù)持久化、一致性也提出了要求。

JIMDB在某些極端情況下容易引發(fā)全量復(fù)制進(jìn)而影響請求，宕機(jī)風(fēng)險越來越高，由于JIMDB架構(gòu)上采用了單線程多進(jìn)程架構(gòu)，導(dǎo)致CPU成為瓶頸。同時服務(wù)器不斷擴(kuò)容帶來運(yùn)維的難度，數(shù)據(jù)量不斷增加導(dǎo)致純內(nèi)存存儲的成本加大，服務(wù)器投入邊際效應(yīng)顯現(xiàn)。

另一面隨著Google發(fā)布Spanner論文后，國內(nèi)外像TiDB、CRDB相繼推出相關(guān)數(shù)據(jù)庫產(chǎn)品或服務(wù)來解決數(shù)據(jù)庫的可擴(kuò)展問題。2017年Google將Spanner商業(yè)化，也進(jìn)一步驗(yàn)證了NewSQL作為未來數(shù)據(jù)庫發(fā)展方向的正確性。

2014年，Gartner的一份報告中使用“混合事務(wù)分析處理（HTAP）”一詞描述新型的應(yīng)用程序架構(gòu)，以打破OLTP和OLAP之間的隔閡，實(shí)現(xiàn)實(shí)時業(yè)務(wù)決策。這種架構(gòu)具備顯而易見的優(yōu)勢——不但避免了繁瑣且昂貴的ETL操作，而且可以更快地對最新數(shù)據(jù)進(jìn)行分析。這種快速分析數(shù)據(jù)的能力將成為未來企業(yè)的核心競爭力之一。

就當(dāng)前的用戶需求和軟硬件技術(shù)發(fā)展?fàn)顩r來看，集成數(shù)據(jù)平臺將能滿足絕大數(shù)用戶的場景，古人說“天下大勢，分久必合、合久必分”，這句話用在數(shù)據(jù)處理領(lǐng)域也不為過。需求和技術(shù)是一對矛盾，當(dāng)這對矛盾緩和時，數(shù)據(jù)處理領(lǐng)域?qū)⒏呄蛴谡?；而?dāng)這對矛盾尖銳時，數(shù)據(jù)處理領(lǐng)域?qū)②呌诜稚ⅰ?/span>

一方面是傳統(tǒng)的OLTP數(shù)據(jù)庫慢慢向NoSQL靠攏，一方面是像TiDB由KV向SQL靠攏，未來整合的趨勢更為明顯。我們詳細(xì)調(diào)研了開源的TiDB與CRDB，發(fā)現(xiàn)并不適合我們的業(yè)務(wù)，TiDB用rust開發(fā)底層采用RocksDB磁盤存儲，滿足不了我們的高性能讀寫要求，電商大促的場景對性能延時有極致的要求；而CRDB上層SQL協(xié)議是采用PG，也不符合我們的業(yè)務(wù)，我們業(yè)務(wù)大量還是MySQL生態(tài)。所以我們決定自研，徹底取代Redis+數(shù)據(jù)庫架構(gòu)，解決數(shù)據(jù)強(qiáng)一致的問題，當(dāng)然我們也不是從0開始，而是參考借鑒了Spanner的論文、TiDB、RocksDB、Redis、Raft論文等。

三、架構(gòu)設(shè)計及應(yīng)用場景

1、整體架構(gòu)

Master：

集群部署，一般線上推薦至少部署3個節(jié)點(diǎn)，是整個集群的管理模塊，其主要工作有三個：

• 存儲集群的元信息（某個Key存儲在哪個DS節(jié)點(diǎn)）；

• 對DS集群進(jìn)行調(diào)度和負(fù)載均衡（如數(shù)據(jù)的遷移、Raft group leader的遷移等）；

• 分配全局唯一且遞增的事務(wù)ID。

DS cluster：

存儲層DS負(fù)責(zé)存儲數(shù)據(jù)，從外部看DS是一個分布式的提供事務(wù)的Key-Value存儲引擎。存儲數(shù)據(jù)的基本單位是Range，每個Region負(fù)責(zé)存儲一個Key Range （從StartKey到EndKey的左閉右開區(qū)間）的數(shù)據(jù)，每個DS節(jié)點(diǎn)會負(fù)責(zé)多個。DS使用Raft協(xié)議做復(fù)制，保持?jǐn)?shù)據(jù)的一致性和容災(zāi)。副本以Range為單位進(jìn)行管理，不同節(jié)點(diǎn)上的多個Range構(gòu)成一個Raft Group，互為副本。數(shù)據(jù)在多個DS之間的負(fù)載均衡由Master調(diào)度，這里也是以Range為單位進(jìn)行調(diào)度。

Proxy：

屬于計算層，可以水平擴(kuò)展，兼容標(biāo)準(zhǔn)的SQL與Redis協(xié)議，負(fù)責(zé)接收SQL請求，處理SQL相關(guān)的邏輯，并通過Master找到存儲計算所需數(shù)據(jù)的DS地址，與DS交互獲取數(shù)據(jù)，最終返回結(jié)果。Proxy是無狀態(tài)的，其本身并不存儲數(shù)據(jù)，只負(fù)責(zé)計算，可以無限水平擴(kuò)展，可以通過負(fù)載均衡組件（如LVS、HAProxy或F5）對外提供統(tǒng)一的接入地址。

2、應(yīng)用場景

JIMKV具備高吞吐、低延遲、高可用、強(qiáng)一致、可擴(kuò)展、高可靠、多協(xié)議支持、可插拔存儲引擎設(shè)計、智能分層存儲、分布式事務(wù)等關(guān)鍵特性，因此適用于我們以下這些應(yīng)用場景：

• 數(shù)據(jù)倉庫：可以存儲和處理海量數(shù)據(jù)，支持高并發(fā)的實(shí)時讀寫，比如訂單數(shù)據(jù)庫、交易數(shù)據(jù)庫、存儲數(shù)據(jù)庫、信息采集數(shù)據(jù)庫等等；

• 替換MySQL數(shù)據(jù)倉庫：大數(shù)據(jù)量下，數(shù)據(jù)增長很快，接近單機(jī)處理大極限，不想分庫分表或者使用數(shù)據(jù)庫中間件等對業(yè)務(wù)侵入性較大、對業(yè)務(wù)有約束的Sharding方案，而JIMKV新一代業(yè)務(wù)層則支持MySQL協(xié)議，并提供遷移工具；

• 緩存加速數(shù)據(jù)倉庫：JIMKV的多線程架構(gòu)使得低延遲、點(diǎn)讀性能媲美Redis，單實(shí)例支持更大的吞吐、在需要提供緩存進(jìn)行系統(tǒng)加速的場景；

• 金融級OLTP業(yè)務(wù)：JIMKV具備金融級安全保證，支持金融級OLTP業(yè)務(wù)（交易、支付、賬單、結(jié)算、金融等等）。
  

四、京東商品詳情業(yè)務(wù)庫應(yīng)用實(shí)踐

目前JIMKV作為京東下一代分布式數(shù)據(jù)庫，內(nèi)部許多原JIMDB客戶開始陸續(xù)遷移業(yè)務(wù)到JIMKV上，在成本與性能方面取得了很好的效果。下面我們以商品詳情業(yè)務(wù)庫為例，介紹我們內(nèi)部JIMKV實(shí)踐的收益。

商品詳情頁在緩存數(shù)據(jù)中屬于實(shí)時性要求不高的數(shù)據(jù)，但是流量特別大，單個KV比較大，促銷某些爆款商品容易形成熱點(diǎn)數(shù)據(jù)。冷熱分層存儲在保證性能的同時最大節(jié)省用戶成本。所謂冷熱數(shù)據(jù)分層存儲，就是根據(jù)數(shù)據(jù)的使用頻率、value大小、最后訪問時間等特征將數(shù)據(jù)進(jìn)行冷熱分層后，再采用相應(yīng)適配的物理存儲介質(zhì)進(jìn)行存儲，并通過不同存儲介質(zhì)之間優(yōu)勢互補(bǔ)，達(dá)到延長保存期限、降低存儲成本、提高存儲效率、增進(jìn)安全可靠性的海量數(shù)據(jù)存儲要求。

簡單來說，經(jīng)常被訪問的數(shù)據(jù)稱為熱數(shù)據(jù)，而較少被訪問的數(shù)據(jù)稱為冷數(shù)據(jù)。其中熱數(shù)據(jù)適合內(nèi)存存儲，實(shí)現(xiàn)高性能訪問；而冷數(shù)據(jù)，則適合使用安全可靠性高、存儲壽命長、單位存儲成本低的磁盤存儲介質(zhì)。冷熱數(shù)據(jù)之間隨著訪問是可以進(jìn)行動態(tài)平衡的。JIMKV采用靈活的可插拔多存儲引擎支持，比如磁盤我們支持RocksDB、LevelDB、WiscKeyDB等，而內(nèi)存我們支持Bw-tree、masstree等，用戶可根據(jù)自己的業(yè)務(wù)場景靈活配置。 

1、解決讀寫放大

眾所周知，傳統(tǒng)的KV持久化存儲一般都采用基于LSM-Tree的LevelDB或RocksDB，能將離散的隨機(jī)寫請求都轉(zhuǎn)換成批量的順序?qū)懻埱?，以此提高寫性能。但是傳統(tǒng)在的LSM-Tree很難避免讀寫放大的問題。

• 讀放大（Read Amplification）。LSM-Tree的讀操作需要從新到舊（從上到下）一層一層查找，直到找到想要的數(shù)據(jù)。這個過程可能需要不止一次I/O。特別是range query的情況，影響很明顯；

• 空間放大（Space Amplification）。因?yàn)樗械膶懭攵际琼樞驅(qū)懀╝ppend-only）的，不是in-place update，所以過期數(shù)據(jù)不會馬上被清理掉。RocksDB和LevelDB通過后臺的compaction來減少讀放大（減少SST文件數(shù)量）和空間放大（清理過期數(shù)據(jù)），但也因此帶來了寫放大（Write Amplification）的問題；

• 寫放大。實(shí)際寫入磁盤的數(shù)據(jù)大小和程序要求寫入數(shù)據(jù)大小之比。正常情況下，HDD/SSD觀察到的寫入數(shù)據(jù)多于上層程序?qū)懭氲臄?shù)據(jù)。原因是在compact的過程中，我需要額外的進(jìn)行寫操作以便能夠?qū)?shù)據(jù)從一個level寫入到另一個level，所以這個過程就增加了寫入量。

現(xiàn)在SSD逐漸成為主流存儲，但compacion帶來的寫放大問題顯得越來越嚴(yán)重：

• SSD順序讀寫性能比隨機(jī)讀寫性能好一些，但是差距并沒有HDD那么大。所以，順序?qū)懴啾入S機(jī)寫帶來的好處，能不能抵消寫放大帶來的開銷，這是個問題；

• SSD的使用壽命和其寫入量有關(guān)，寫放大太嚴(yán)重會大大縮短SSD的使用壽命。因?yàn)镾SD不支持覆蓋寫，必須先擦除（erase）再寫入。而每個SSD block（block是SSD擦除操作的基本單位）的平均擦除次數(shù)是有限的。
  

寫放大在兩個level之間能夠達(dá)到10以上。又因?yàn)檫@里有7個level，所以從level 1~level 6，可能會使寫放大達(dá)到50。

WiscKeyDB通過以下四點(diǎn)解決讀寫放大的問題：

• 鍵值分開存儲，Key仍然存在LSM-tree中，Value存在額外的日志文件（vLog）中；

• 對于無序的值數(shù)據(jù)，利用SSD并行隨機(jī)讀以加速讀取速度；

• 使用獨(dú)特的崩潰一致性和垃圾回收策略以高效的管理Value日志文件；

• 去除WAL并且不影響一致性，提升小數(shù)據(jù)流量的寫入性能。

2、冷熱調(diào)度

配置參數(shù)maxmemory，maxdisksize

Maxmemory > 0默認(rèn)開啟masstree引擎（內(nèi)存數(shù)據(jù)庫）。

maxmemory = 0默認(rèn)開啟RocksDB引擎（磁盤數(shù)據(jù)庫）。

1）熱→冷：使用內(nèi)存>maxmemory

根據(jù)客戶端命令（比如set sk svalue），來計算是否需要增加字節(jié)，判斷內(nèi)存使用量如果>maxmemory，就啟動RocksDB引擎，按照配置的策略進(jìn)行尾淘汰，淘汰任務(wù)加入異步IO任務(wù)隊(duì)列，不影響主線程其他命令的執(zhí)行，IO線程取出異步任務(wù)，將key value存儲到RocksDB，通知主線程。主線程收到完成的通知后釋放masstree中value的內(nèi)存，在元數(shù)據(jù)中標(biāo)記此value在冷存儲中。

2）冷→熱：使用內(nèi)存<maxmemory*70%

用戶訪問的key如果在RocksDB，且當(dāng)前value大小+使用內(nèi)存<maxmemory開始進(jìn)行首淘汰，訪問的key的value不在內(nèi)存中，但是客戶端命令類型（比如exist,ttl之類的）不需要查詢原有value，正常執(zhí)行；訪問的key的value在冷，就加入異步IO任務(wù)，不阻塞主線程其他命令執(zhí)行。IO線程取出異步任務(wù)，從RocksDB中查詢對應(yīng)的value，通知主線程，將value返回給客戶端，將value插入masstree中，更新key中元數(shù)據(jù)中的冷熱標(biāo)志，刪除RocksDB里的冷key。

3、總結(jié)

我們根據(jù)詳情頁的數(shù)據(jù)特點(diǎn)磁盤采用WiscKeyDB存儲引擎，內(nèi)存采用masstree存儲引擎，masstree結(jié)合了trie與b+tree的特點(diǎn)，節(jié)省內(nèi)存性能上由于RCU細(xì)粒度的鎖機(jī)制比b+tree性能好很多，而WiscKeyDB是在RocksDB基礎(chǔ)上大大減少了讀寫放大。針對熱點(diǎn)數(shù)據(jù)我們sdk也是支持客戶端緩存進(jìn)行優(yōu)化，采用新的混合存儲以后我們在滿足客戶性能要求的同時，降低了75%左右的存儲成本。

五、后續(xù)規(guī)劃

1、智能運(yùn)維

目前我們通過高可用架構(gòu)的master來調(diào)度、balance、遷移、故障恢復(fù)等，能否結(jié)合機(jī)器學(xué)習(xí)讓數(shù)據(jù)庫能否擁有真正的智能，能夠自我維護(hù)、自我修復(fù)以及自我性能調(diào)優(yōu)等在未來是一個好的思路。

2、OLAP場景支持

目前我們針對MySQL兼容程度還不是很夠，只能滿足普通的增刪改查以及ddl操作，針對聚合、join等分析功能還未完全實(shí)現(xiàn)，這是我們下一步的工作重點(diǎn)。

3、新硬件的支持

隨著硬件性能的提升，內(nèi)核中的網(wǎng)絡(luò)棧和存儲棧帶來的性能瓶頸越來越明顯，為縮短IO路徑、解決NVMe SSD在傳統(tǒng)IO棧上的性能問題，Linux內(nèi)核從4.x開始引入了新的NVMe IO棧，新的IO子系統(tǒng)完全擯棄了傳統(tǒng)的通用塊層和SCSI子系統(tǒng)，而kernel bypass（繞過內(nèi)核）是解決系統(tǒng)網(wǎng)絡(luò)棧和存儲棧性能瓶頸的另外一種方式，并輔以各種性能調(diào)優(yōu)手段（CPU pin、無鎖隊(duì)列），從而達(dá)到更高的性能。

目前市場上也有多種類似的技術(shù)，如DPDK、NETMAP、SPDK、PF_RING、RDMA等，如何利用新的硬件（Nvme SSD、Persistent Memory、Kernel bypass GPU、FPGA）結(jié)合JIMKV來提高穩(wěn)定性與性能也是我們未來的規(guī)劃。

---

特別推薦一個分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒關(guān)注的小伙伴，可以長按關(guān)注一下：

長按訂閱更多精彩▼
如有收獲，點(diǎn)個在看，誠摯感謝