一、背景

過去幾年，攜程技術(shù)保障部門在Redis治理方面做了很多工作，解決了運(yùn)營(yíng)上的問題，在私有云上也積累了豐富的經(jīng)驗(yàn)。后又通過引入Kvrocks，在公有云上實(shí)現(xiàn)降本增效的目的，從而支撐了公司的國(guó)際化戰(zhàn)略。

與此同時(shí)，國(guó)內(nèi)業(yè)務(wù)部門存在降低基礎(chǔ)建設(shè)成本的客觀需要，有些業(yè)務(wù)方期望提供一種非傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)來解決某些高性能海量空間的業(yè)務(wù)需求，并在此基礎(chǔ)上支持特殊定制化以面對(duì)后疫情時(shí)代的挑戰(zhàn)。這些變化使我們開始思考，是不是可以參考公有云上的思路，在私有云上構(gòu)建一種持久化數(shù)據(jù)庫(kù)，來滿足業(yè)務(wù)方對(duì)高性能、低成本、海量、持久化的需求。

二、面對(duì)的問題

回顧之前在公有云上的方案，目的明確。因?yàn)楣性频膬?nèi)存較貴，我們將Redis的數(shù)據(jù)存在SSD上來降低成本，選型了Kvrocks，并自研實(shí)現(xiàn)支持Redis的復(fù)制協(xié)議，將公有云上的成本降低了60%(圖1)。 

圖1 

隨著業(yè)務(wù)發(fā)展和Redis集群的日益增長(zhǎng)，需求更加多樣化，需要在私有云上同樣能有一種持久化的KV存儲(chǔ)系統(tǒng)來提供服務(wù)，包括：

1. KV存儲(chǔ)和讀寫的場(chǎng)景，Redis能提供的存儲(chǔ)上限過低，需要有大容量的KV存儲(chǔ)系統(tǒng);
2. 數(shù)據(jù)持久化，而不是像Redis那樣重啟數(shù)據(jù)即丟失;
3. 節(jié)約Redis的使用成本，畢竟私有云上的Redis集群非常龐大;
4. 提供類似selectforudpate的語(yǔ)義來實(shí)現(xiàn)庫(kù)存之類字段的扣減，而不是依賴外部的一些組件，比如分布式鎖;
5. 數(shù)據(jù)能提供相比Redis更高的一致性，比如支持同步復(fù)制。

我們仔細(xì)分析業(yè)務(wù)需求和業(yè)界可選的方案，以期望找到一種持久化的KV數(shù)據(jù)庫(kù)，能兼容Redis滿足大容量和成本降低的需求，而又不局限于Redis，能提供更多樣化的能力來支撐業(yè)務(wù)的訴求。

三、調(diào)研和選擇

我們調(diào)研了業(yè)界大部分的NoSQL/NewSQL數(shù)據(jù)庫(kù)，主要考慮以下幾個(gè)方面。

是否為業(yè)界主流

主流有兩層含義：第一，是否流行，比如github上的star數(shù)，是否是頂級(jí)開源基金的項(xiàng)目，或是否有大廠背書;第二，其理念是否主流，如現(xiàn)在使用最廣的關(guān)系型數(shù)據(jù)庫(kù)MySQL，以及NewSQL TiDB，其相關(guān)概念如半同步復(fù)制，GTID，raft，計(jì)算存儲(chǔ)分離等概念都比較深入人心。

是否有成熟的中間件

中間件成熟是非常重要的一種能力，一旦選擇了一種不合適的數(shù)據(jù)庫(kù)，中間件相關(guān)的路由，打點(diǎn)，監(jiān)控，降級(jí)，熔斷，DR切換等每一項(xiàng)都需要投入大量的人力物力來做，此外穩(wěn)定的中間件也是需要長(zhǎng)時(shí)間打磨才能被業(yè)務(wù)方信賴，如果能復(fù)用現(xiàn)有中間件的大部分能力，能節(jié)約大量人力物力。

集群運(yùn)維治理配套是否完善

選擇一種KV數(shù)據(jù)庫(kù)，除了中間件外，治理相關(guān)的如集群擴(kuò)容，縮容，實(shí)例的遷移，資源利用率等一樣要考慮進(jìn)來。無(wú)論哪種數(shù)據(jù)庫(kù)，部署后的運(yùn)維治理相關(guān)，能復(fù)用現(xiàn)有的能力最好，如果不能復(fù)用，需要考慮：擴(kuò)容到10倍需要多久時(shí)間，是否可以縮容?是否好遷移，對(duì)業(yè)務(wù)透明?大規(guī)模部署后，資源利用率是否可以提升?

性能是否滿足要求，是否支持10X的擴(kuò)展

上面說的這幾點(diǎn)，如果都滿足，但性能不滿足或者不支持10X擴(kuò)展，那也將一票否決。性能也是重要考量的一塊，希望找到一種性能優(yōu)異的KV數(shù)據(jù)庫(kù)。

是否可以二次開發(fā)，獨(dú)立演進(jìn)

對(duì)于攜程這樣體量或相似體量的公司來說，持久化KV的數(shù)據(jù)庫(kù)大多有自研的或基于開源二次開發(fā)的數(shù)據(jù)庫(kù)，比如美團(tuán)的Cellar，餓了么的Tidis，360的pika等，我們同樣需要選擇一種易于二次開發(fā)或方便擴(kuò)展的數(shù)據(jù)庫(kù)，來開發(fā)自定義的特性支撐業(yè)務(wù)。

調(diào)研的過程受制于篇幅限制，不再一一展開，最終我們繼續(xù)選擇了Kvrocks來作為治理演進(jìn)的對(duì)象，其他的NoSQL/NewSQL有各種不足，而Kvrocks受益于Redis運(yùn)維治理的成熟，可以復(fù)用現(xiàn)有的大部分Redis中間件和運(yùn)維治理的能力，在攜程與Redis幾乎無(wú)差異的部署/使用方式，當(dāng)下無(wú)疑是最適合的一種持久化KV數(shù)據(jù)庫(kù)。

四、從Kvrocks到TRocks

經(jīng)過不斷的開發(fā)迭代和使用，最終我們將新系統(tǒng)命名為TRocks(Trip+Kvrocks)，作為攜程自己的持久化KV數(shù)據(jù)庫(kù)。相比于原來的Kvrocks，除了與Redis可以互通協(xié)議互為主從外，主要是基于以下幾個(gè)方面的改進(jìn)。

1、功能增強(qiáng)

獨(dú)占鎖

一些業(yè)務(wù)方存在著流程協(xié)調(diào)，執(zhí)行順序的限制，往往會(huì)需要使用分布式鎖，比如扣減庫(kù)存的邏輯。常見的方式是引入一個(gè)第三方的分布式系統(tǒng)，將鎖標(biāo)識(shí)存儲(chǔ)在那里用于共享訪問，以達(dá)到鎖的目的。

這樣做雖然常見，但也有一些問題，首先需要引入額外的系統(tǒng)，并單獨(dú)考慮各種異常情況的處理，增加了整個(gè)應(yīng)用的復(fù)雜度。其次標(biāo)識(shí)位往往有一定含義或者能與當(dāng)前業(yè)務(wù)數(shù)據(jù)做關(guān)聯(lián)，這就相當(dāng)于額外存儲(chǔ)了一份業(yè)務(wù)數(shù)據(jù)，存在一定的安全隱患。同時(shí)多個(gè)應(yīng)用可能共用一套外部分布式系統(tǒng)來處理鎖，這就無(wú)形中增加了系統(tǒng)的訪問壓力，一旦出現(xiàn)問題將影響多個(gè)依賴方，缺乏隔離性。

為了解決此類問題，TRocks在內(nèi)部實(shí)現(xiàn)了基于Key力度的鎖功能，將其分布式部署并作為應(yīng)用的業(yè)務(wù)數(shù)據(jù)庫(kù)時(shí)，其本身就擁有了分布式鎖的能力(圖2)。對(duì)鎖的處理和業(yè)務(wù)數(shù)據(jù)在一起，無(wú)需引入多余的系統(tǒng)，降低復(fù)雜度，幫助業(yè)務(wù)方專注于業(yè)務(wù)代碼的開發(fā)。

圖2 

為了保證請(qǐng)求的唯一性和類似raft那樣支持冪等重試的功能，每個(gè)請(qǐng)求需要帶上標(biāo)識(shí)唯一性的clientid和自增seq，這些metadata和本身的data會(huì)被當(dāng)成一個(gè)writebatch寫入到rocksdb中，后續(xù)還會(huì)同步到slave上，從而保證整條鏈路上請(qǐng)求的原子性。

復(fù)合命令

由于Redis命令本身的限制，有些業(yè)務(wù)方反饋實(shí)現(xiàn)一個(gè)功能，比如對(duì)hash key進(jìn)行超時(shí)處理需要進(jìn)行2次操作，一次設(shè)置值，一次設(shè)置超時(shí)。雖然中間件將這層邏輯封裝之后對(duì)外只提供一個(gè)api，但內(nèi)部執(zhí)行仍然是2個(gè)命令，可能存在原子性問題。TRocks針對(duì)這種情況增加了一些復(fù)合功能的命令，調(diào)用這些命令可以實(shí)現(xiàn)相同的效果并保證原子性，同時(shí)這些功能對(duì)用戶是透明的，直接調(diào)用客戶端相應(yīng)api即可使用。

2、可用性增強(qiáng)

可調(diào)一致性

Kvrocks本身的主從復(fù)制邏輯與Redis相似，都是通過異步方式進(jìn)行的。在這種方式下，如果出現(xiàn)網(wǎng)絡(luò)斷開或者master宕機(jī)，數(shù)據(jù)還未來得及同步，就會(huì)出現(xiàn)數(shù)據(jù)丟失的情況。為了避免此類問題，TRocks加入了類似Mysql的半同步復(fù)制來提高數(shù)據(jù)的一致性。我們可以通過打開半同步方式并指定至少需要參與的半同步slave的數(shù)量來啟用該功能，提高災(zāi)備能力。

例如一個(gè)1主4從的集群，設(shè)定需要等待任意2臺(tái)Slave響應(yīng)。

如圖3所示，當(dāng)滿足響應(yīng)的slave為2的時(shí)候，半同步即可認(rèn)為完成，即使此時(shí)另外兩臺(tái)slave可能還未完成同步工作。 

但這種方式在多機(jī)房部署的情況仍然可能存在問題。因?yàn)榫嚯x的關(guān)系，相同機(jī)房的數(shù)據(jù)傳輸速率會(huì)更高，所以master復(fù)制到和其在同一個(gè)機(jī)房的slave通常情況會(huì)更快(圖4)。 

這樣就很容易發(fā)生同機(jī)房的slave數(shù)據(jù)復(fù)制的進(jìn)度要快于異地機(jī)房的slave。如果發(fā)生機(jī)房級(jí)的故障，導(dǎo)致master所在集群的服務(wù)全都無(wú)法正常工作，這個(gè)時(shí)候就可能發(fā)生數(shù)據(jù)丟失。

為此我們?cè)诎胪綇?fù)制的基礎(chǔ)上增加了IDC模式，使得即使初始條件已經(jīng)滿足，也需要至少存在相關(guān)IDC的slave反饋才能完成整個(gè)復(fù)制流程。IDC模式有兩種，本地復(fù)制和異地復(fù)制。

以異地模式為例，如果返回slave的數(shù)量滿足條件，且包含至少一臺(tái)來自于master所在機(jī)房不同的slave，則半同步復(fù)制完成。如果當(dāng)前響應(yīng)中未包含非master集群的slave，則繼續(xù)等待，直到master接收到一臺(tái)來自異地的slave的反饋，半同步才能完成(圖5)。 

盡管異地模式數(shù)據(jù)的安全性更高，但也會(huì)影響整個(gè)系統(tǒng)的性能，這個(gè)性能差正常情況下取決于不同機(jī)房之間的網(wǎng)絡(luò)延遲。基于對(duì)性能和數(shù)據(jù)可用性的不同要求，使用方可以酌情選擇全異步復(fù)制(即關(guān)閉半同步)，半同步 & 半同步(本地)復(fù)制或者半同步(異地)復(fù)制。

全量同步復(fù)制抑制

上面說到異步復(fù)制在異常情況下可能存在數(shù)據(jù)缺失的情況，如果再加上運(yùn)維系統(tǒng)對(duì)主從關(guān)系的調(diào)整，就會(huì)發(fā)生數(shù)據(jù)沖突。而我們目前TRocks的版本還在快速迭代中，希望每次升級(jí)版本能夠?qū)τ脩敉该鳎欢聦?shí)并非如此。

假設(shè)存在master A和slave B，正常情況下A和B的數(shù)據(jù)是保持一致的(綠色部分)，但當(dāng)A發(fā)生宕機(jī)的時(shí)候，B可能還未同步到A的最新數(shù)據(jù)，這時(shí)B的數(shù)據(jù)不再增加。但隨后哨兵發(fā)現(xiàn)master無(wú)法訪問，就把B提升為master并開始處理寫入數(shù)據(jù)(藍(lán)色部分)。當(dāng)一段時(shí)間后，A系統(tǒng)恢復(fù)，重新加入進(jìn)集群，此時(shí)A會(huì)變?yōu)閙asterB的slave，并嘗試從B中同步數(shù)據(jù)，這里就可能存在沖突區(qū)(圖6)。 

按照Kvrocks初始的復(fù)制邏輯，A會(huì)認(rèn)為自身數(shù)據(jù)存在問題，并放棄全部數(shù)據(jù)然后從頭開始進(jìn)行全量同步B的數(shù)據(jù)。這個(gè)行為本身沒有問題。然而實(shí)際生產(chǎn)環(huán)境下，如果數(shù)據(jù)量很大的話，全量同步的耗時(shí)會(huì)比較長(zhǎng)，而硬盤相比內(nèi)存的帶寬至少小兩個(gè)數(shù)量級(jí)，因?yàn)槲覀兊膶?shí)例都是容器化部署，這有可能導(dǎo)致災(zāi)難性的后果，A在同步數(shù)據(jù)的時(shí)候會(huì)產(chǎn)生大量的IO，從而可能會(huì)影響A/B所在的宿主機(jī)上的所有的實(shí)例。

在數(shù)據(jù)一致性要求沒有那么高的場(chǎng)景中，僅僅因?yàn)榭赡艿膸讞l數(shù)據(jù)不一致就重新同全量同步，代價(jià)非常昂貴。所以我們希望在非強(qiáng)一致性條件下，系統(tǒng)可以容忍極少量的數(shù)據(jù)差異，盡可能避免全量同步以便充分利用資源。

我們的方案是當(dāng)檢測(cè)到數(shù)據(jù)不一致的時(shí)候，主從之間會(huì)進(jìn)行交互協(xié)調(diào)，計(jì)算出沖突區(qū)的范圍，并從沖突區(qū)之后第一條數(shù)據(jù)開始進(jìn)行同步。為什么不是直接從沖突區(qū)后面開始同步?這里需要有個(gè)概念，TRocks/Kvrocks的數(shù)據(jù)都是追加形式的，增刪改都會(huì)在log文件中追加一條記錄，并提供起始位置(Sequence)，對(duì)應(yīng)不同的Redis類型的記錄會(huì)有不同的長(zhǎng)度(Count)，比如一條SET指令對(duì)應(yīng)的Sequence會(huì)累加1，而HSET指令會(huì)累加2。

從Sequence到Sequence+Count就是一條記錄的數(shù)據(jù)范圍。當(dāng)重新同步的時(shí)候，沖突區(qū)的結(jié)束位置如果處于正常數(shù)據(jù)的中間，這樣是沒有辦法取得完整數(shù)據(jù)的，所以需要從沖突區(qū)后第一條數(shù)據(jù)開始。 

而沖突區(qū)與同步開始之間的區(qū)域是補(bǔ)足區(qū)(圖7)，我們通過插入空白數(shù)據(jù)來進(jìn)行填補(bǔ)，所以對(duì)于A和B來說，他們之間不一致區(qū)域是沖突區(qū)和補(bǔ)足區(qū)的總和。而對(duì)于沖突的部分，我們會(huì)記錄下兩邊的差異，真有差異發(fā)生時(shí)，參考git解決沖突的思路，將數(shù)據(jù)的選擇權(quán)交給用戶。

上線該feature后，版本的升級(jí)就變得比較輕松，大部分情況下版本升級(jí)只是一次實(shí)例的拉出重啟拉入，實(shí)例也是秒級(jí)up，升級(jí)過程也基本上對(duì)業(yè)務(wù)做到了透明。

在解決此問題的同時(shí)，我們也注意到master/slave數(shù)據(jù)是對(duì)齊的某些情況下也會(huì)發(fā)生全量同步，檢查下來發(fā)現(xiàn)是pub/sub命令的問題。

這個(gè)命令是哨兵用于訂閱服務(wù)消息的，但Kvrocks的pub/sub是一個(gè)寫操作，這樣就會(huì)造成持續(xù)性的數(shù)據(jù)寫入從而累加rocksdb的Sequence，這樣如果一個(gè)slave宕機(jī)后恢復(fù)，還沒來得及與master同步卻被哨兵寫入了一條無(wú)關(guān)緊要的pub消息，累加了Seq從而觸發(fā)了不必要的全量同步，但實(shí)際上該功能并非必須，所以我們修改Kvrocks處理哨兵pubsub消息的規(guī)則，不去寫之后這個(gè)命令只工作在內(nèi)存中，自然不會(huì)累加rocksdb的Sequence，杜絕這種情況全量同步的可能性。

3、運(yùn)維治理能力增強(qiáng)

水平擴(kuò)縮容 

在之前的Redis治理演進(jìn)之路文章中，我們介紹了一種新的擴(kuò)縮容方案來解決Redis集群版本升級(jí)和擴(kuò)縮容的問題(圖8)，參考同樣的思路，我們繼續(xù)改造BinlogServer來實(shí)現(xiàn)TRocks的集群的水平擴(kuò)縮容，這套方案實(shí)際上不僅解決了擴(kuò)縮容的問題，同時(shí)也解決了Redis到Redis的數(shù)據(jù)遷移，TRocks到TRocks的數(shù)據(jù)遷移，Redis與TRocks之間的互相遷移，也可以幫助用戶平滑的從Redis的訪問過渡到TRocks的訪問。

然而相比Redis擴(kuò)縮容基本不需要考慮內(nèi)存帶寬，硬盤帶寬太窄，而數(shù)據(jù)遷移的時(shí)候流量太大。由于所有數(shù)據(jù)最終都需要在新集群上刷盤，導(dǎo)致遷移過程中目標(biāo)集群的磁盤讀寫會(huì)非常大，又由于我們都是容器化部署，大量的磁盤讀寫也可能會(huì)影響到統(tǒng)一宿主機(jī)上的其他無(wú)關(guān)的應(yīng)用，所以我們調(diào)整了TRocks的寫入限流設(shè)置，以避免大量寫入影響磁盤性能，同時(shí)修改了BinlogServer加入了限流功能，平緩數(shù)據(jù)傳輸?shù)乃俾省?/p>

哨兵多機(jī)房部署

為了保證TRocks集群可以跨機(jī)房容災(zāi)，哨兵需要部署在多個(gè)機(jī)房中，目前我們是三機(jī)房部署。如下圖(圖9)： 

在部署的時(shí)候，遇到了一個(gè)問題，我們發(fā)現(xiàn)哨兵之間經(jīng)常無(wú)法選出leader，需要等下一個(gè)選舉周期(6分鐘)才能重新選出，導(dǎo)致長(zhǎng)時(shí)間無(wú)法確定TRocks master。這個(gè)問題本身跟TRocks沒有太大關(guān)系，只是實(shí)際使用中對(duì)我們故障處理帶來了不小麻煩。

出現(xiàn)無(wú)法選出leader的原因是多個(gè)哨兵同時(shí)發(fā)起選舉希望成為leader，導(dǎo)致最終每個(gè)哨兵都選擇了自己，無(wú)法達(dá)成共識(shí)。查看源碼發(fā)現(xiàn)官方已經(jīng)為發(fā)起選舉前設(shè)置了隨機(jī)的間隔時(shí)間(50~100ms)，但實(shí)際操作中發(fā)現(xiàn)這個(gè)隨機(jī)間隔反而增加了發(fā)生選角失敗的可能，考慮應(yīng)該是隨機(jī)時(shí)間太短導(dǎo)致，所以我們將隨件間隔修改為100~200ms，同時(shí)在哨兵發(fā)現(xiàn)master宕機(jī)之后就立即發(fā)起選舉來盡可能規(guī)避無(wú)法選主的問題。

五、一些數(shù)據(jù)

1、性能數(shù)據(jù)

TRocks在內(nèi)網(wǎng)上線后，在各個(gè)業(yè)務(wù)線都得到了廣泛的使用，排除公有云的部分，私有云上已經(jīng)有將近2K的實(shí)例，10T+的數(shù)據(jù)量，下圖(圖10，圖11)可以看到同樣的數(shù)據(jù)寫TRocks和Redis的性能對(duì)比。平均響應(yīng)時(shí)間，99.9%在同一個(gè)水平，并且我們還可以看到，得益于自定義的命令，同樣的功能相比Redis更加簡(jiǎn)潔。 

根據(jù)我們跟業(yè)務(wù)方壓測(cè)，一臺(tái)40C和2塊RAID0的SATA SSD在保證良好響應(yīng)的前提下(99.9%<10ms)約能提供讀寫的QPS為8-10W，其中value<1k。而如果換成NVME SSD這個(gè)QPS可以提升3-5倍。

2、成本數(shù)據(jù)

假設(shè)TRocks都是容器化部署，并且一臺(tái)40C的宿主機(jī)上可以部署20個(gè)實(shí)例，每個(gè)實(shí)例大小為40G，因?yàn)門Rocks相比Redis有不小的壓縮功能(約3-7倍的壓縮率)，如果將Redis的數(shù)據(jù)導(dǎo)過來可以平穩(wěn)運(yùn)行，那么TRocks相比Redis約可以節(jié)約90%的成本。

既然能省這么多成本，是否所有的Redis都可以用TRocks來代替，我們是否需要將私有云上所有的Redis都替換成為TRocks?

答案都是否定的，也不是我們推廣TRocks的初衷，原因有以下兩點(diǎn)：

• 如上文所提到的，我們希望TRocks能擁有Redis的大部分能力，而又不僅僅局限于Redis，希望它更是一個(gè)通用的KV數(shù)據(jù)庫(kù)，能提供更多樣化的能力來支撐業(yè)務(wù)的訴求。
• 硬盤的帶寬與內(nèi)存有2個(gè)數(shù)量級(jí)的差距，而這些先天不足也無(wú)法滿足某些Redis場(chǎng)景的需求。比如大Key(>100K)響應(yīng)和Redis還是有一定的差距，此外某些數(shù)據(jù)量小并且單個(gè)實(shí)例訪問QPS較高的實(shí)例，用TRocks來替換也并不合適，因?yàn)橐?guī)?；\(yùn)維治理，我們需要考慮整個(gè)宿主機(jī)和每個(gè)實(shí)例是否能平穩(wěn)運(yùn)行，一般來說單個(gè)實(shí)例>10G，QPS<5K 是比較適合的。當(dāng)然NVME SSD可以極大縮短大Key的響應(yīng)時(shí)間和提升單個(gè)實(shí)例QPS的上限。

六、未來規(guī)劃

1、復(fù)合命令增強(qiáng)

我們調(diào)研發(fā)現(xiàn)，業(yè)務(wù)經(jīng)常為了獲取一條數(shù)據(jù)，需要多次查詢TRocks，類似二度人脈的取數(shù)據(jù)邏輯，多次的網(wǎng)絡(luò)IO會(huì)導(dǎo)致耗時(shí)增加，而設(shè)計(jì)通用的命令來支持業(yè)務(wù)需求，減少網(wǎng)絡(luò)IO變得非常重要，此外還有些用戶詢問TRocks的hash類型中的subkey是否也可以實(shí)現(xiàn)過期。由于hash功能目前仍然是遵照Redis的規(guī)則，所以現(xiàn)在是按照整個(gè)hash key一起過期而不能實(shí)現(xiàn)內(nèi)部數(shù)據(jù)項(xiàng)的過期。這個(gè)需求是有一定價(jià)值的，未來我們會(huì)通過提供一個(gè)特殊的hash結(jié)構(gòu)來實(shí)現(xiàn)此類功能。

2、引入checkpoint

Kvrocks1.X在進(jìn)行全量復(fù)制時(shí)，master會(huì)生成硬的backup，會(huì)拷貝文件產(chǎn)生大量的IO，而官方2.0版本已經(jīng)用Rocksdbcheckpoint解決了這個(gè)問題，我們也已經(jīng)將2.0版本merge過來測(cè)試，準(zhǔn)備適時(shí)升級(jí)上線。

3、使用NVME SSD

目前攜程的大量TRocks還是跑在SATA接口的SSD上，而據(jù)我們的測(cè)試下來兩塊SATA raid0的帶寬大約為800MB/S，導(dǎo)致硬盤非常容易跑滿，相比之下，NVME SSD的帶寬基本都是幾G起步，并且我們測(cè)試下來NVME SSD在小的壓力下，對(duì)于SATA SSD性能有3-5倍的提升，而對(duì)于大Key的情況(超過100K)和大的壓力下，NVME SSD的性能提升可以高達(dá)10-100倍。因此我們已經(jīng)計(jì)劃將SATA SSD全換成NVME SSD，進(jìn)一步提升TRocks的性能。