徹底取代Redis+數(shù)據(jù)庫(kù)架構(gòu)，京東618穩(wěn)了！

作者介紹

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

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

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

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

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

1、自動(dòng)故障檢測(cè)恢復(fù)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1、整體架構(gòu)

Master：

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

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

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

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

DS cluster：

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

Proxy：

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

2、應(yīng)用場(chǎng)景

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

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

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

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

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

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

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

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

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

1、解決讀寫(xiě)放大

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

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

• 空間放大（Space Amplification）。因?yàn)樗械膶?xiě)入都是順序?qū)懀╝ppend-only）的，不是in-place update，所以過(guò)期數(shù)據(jù)不會(huì)馬上被清理掉。RocksDB和LevelDB通過(guò)后臺(tái)的compaction來(lái)減少讀放大（減少SST文件數(shù)量）和空間放大（清理過(guò)期數(shù)據(jù)），但也因此帶來(lái)了寫(xiě)放大（Write Amplification）的問(wèn)題；

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

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

• SSD順序讀寫(xiě)性能比隨機(jī)讀寫(xiě)性能好一些，但是差距并沒(méi)有HDD那么大。所以，順序?qū)懴啾入S機(jī)寫(xiě)帶來(lái)的好處，能不能抵消寫(xiě)放大帶來(lái)的開(kāi)銷(xiāo)，這是個(gè)問(wèn)題；

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

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

WiscKeyDB通過(guò)以下四點(diǎn)解決讀寫(xiě)放大的問(wèn)題：

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

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

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

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

2、冷熱調(diào)度

配置參數(shù)maxmemory，maxdisksize

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

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

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

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

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

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

3、總結(jié)

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

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

1、智能運(yùn)維

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

2、OLAP場(chǎng)景支持

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

3、新硬件的支持

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

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

---

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

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