攜程持久化KV存儲挑戰Redis，狂省90%成本……
一、背景
過去幾年，攜程技術保障部門在Redis治理方面做了很多工作，解決了運營上的問題，在私有云上也積累了豐富的經驗。后又通過引入Kvrocks，在公有云上實現降本增效的目的，從而支撐了公司的國際化戰略。
與此同時，國內業務部門存在降低基礎建設成本的客觀需要，有些業務方期望提供一種非傳統關系數據庫來解決某些高性能海量空間的業務需求，并在此基礎上支持特殊定制化以面對后疫情時代的挑戰。這些變化使我們開始思考，是不是可以參考公有云上的思路，在私有云上構建一種持久化數據庫，來滿足業務方對高性能、低成本、海量、持久化的需求。
二、面對的問題
回顧之前在公有云上的方案，目的明確。因為公有云的內存較貴，我們將Redis的數據存在SSD上來降低成本，選型了Kvrocks，并自研實現支持Redis的復制協議，將公有云上的成本降低了60%(圖1)。
圖1
隨著業務發展和Redis集群的日益增長，需求更加多樣化，需要在私有云上同樣能有一種持久化的KV存儲系統來提供服務，包括：
- KV存儲和讀寫的場景，Redis能提供的存儲上限過低，需要有大容量的KV存儲系統;
- 數據持久化，而不是像Redis那樣重啟數據即丟失;
- 節約Redis的使用成本，畢竟私有云上的Redis集群非常龐大;
- 提供類似selectforudpate的語義來實現庫存之類字段的扣減，而不是依賴外部的一些組件，比如分布式鎖;
- 數據能提供相比Redis更高的一致性，比如支持同步復制。
我們仔細分析業務需求和業界可選的方案，以期望找到一種持久化的KV數據庫，能兼容Redis滿足大容量和成本降低的需求，而又不局限于Redis，能提供更多樣化的能力來支撐業務的訴求。
三、調研和選擇
我們調研了業界大部分的NoSQL/NewSQL數據庫，主要考慮以下幾個方面。
是否為業界主流
主流有兩層含義：第一，是否流行，比如github上的star數，是否是頂級開源基金的項目，或是否有大廠背書;第二，其理念是否主流，如現在使用最廣的關系型數據庫MySQL，以及NewSQL TiDB，其相關概念如半同步復制，GTID，raft，計算存儲分離等概念都比較深入人心。
是否有成熟的中間件
中間件成熟是非常重要的一種能力，一旦選擇了一種不合適的數據庫，中間件相關的路由，打點，監控，降級，熔斷，DR切換等每一項都需要投入大量的人力物力來做，此外穩定的中間件也是需要長時間打磨才能被業務方信賴，如果能復用現有中間件的大部分能力，能節約大量人力物力。
集群運維治理配套是否完善
選擇一種KV數據庫，除了中間件外，治理相關的如集群擴容，縮容，實例的遷移，資源利用率等一樣要考慮進來。無論哪種數據庫，部署后的運維治理相關，能復用現有的能力最好，如果不能復用，需要考慮：擴容到10倍需要多久時間，是否可以縮容?是否好遷移，對業務透明?大規模部署后，資源利用率是否可以提升?
性能是否滿足要求，是否支持10X的擴展
上面說的這幾點，如果都滿足，但性能不滿足或者不支持10X擴展，那也將一票否決。性能也是重要考量的一塊，希望找到一種性能優異的KV數據庫。
是否可以二次開發，獨立演進
對于攜程這樣體量或相似體量的公司來說，持久化KV的數據庫大多有自研的或基于開源二次開發的數據庫，比如美團的Cellar，餓了么的Tidis，360的pika等，我們同樣需要選擇一種易于二次開發或方便擴展的數據庫，來開發自定義的特性支撐業務。
調研的過程受制于篇幅限制，不再一一展開，最終我們繼續選擇了Kvrocks來作為治理演進的對象，其他的NoSQL/NewSQL有各種不足，而Kvrocks受益于Redis運維治理的成熟，可以復用現有的大部分Redis中間件和運維治理的能力，在攜程與Redis幾乎無差異的部署/使用方式，當下無疑是最適合的一種持久化KV數據庫。
四、從Kvrocks到TRocks
經過不斷的開發迭代和使用，最終我們將新系統命名為TRocks(Trip+Kvrocks)，作為攜程自己的持久化KV數據庫。相比于原來的Kvrocks，除了與Redis可以互通協議互為主從外，主要是基于以下幾個方面的改進。
1、功能增強
獨占鎖
一些業務方存在著流程協調，執行順序的限制，往往會需要使用分布式鎖，比如扣減庫存的邏輯。常見的方式是引入一個第三方的分布式系統，將鎖標識存儲在那里用于共享訪問，以達到鎖的目的。
這樣做雖然常見，但也有一些問題，首先需要引入額外的系統，并單獨考慮各種異常情況的處理，增加了整個應用的復雜度。其次標識位往往有一定含義或者能與當前業務數據做關聯，這就相當于額外存儲了一份業務數據，存在一定的安全隱患。同時多個應用可能共用一套外部分布式系統來處理鎖，這就無形中增加了系統的訪問壓力，一旦出現問題將影響多個依賴方，缺乏隔離性。
為了解決此類問題，TRocks在內部實現了基于Key力度的鎖功能，將其分布式部署并作為應用的業務數據庫時，其本身就擁有了分布式鎖的能力(圖2)。對鎖的處理和業務數據在一起，無需引入多余的系統，降低復雜度，幫助業務方專注于業務代碼的開發。
圖2
為了保證請求的唯一性和類似raft那樣支持冪等重試的功能，每個請求需要帶上標識唯一性的clientid和自增seq，這些metadata和本身的data會被當成一個writebatch寫入到rocksdb中，后續還會同步到slave上，從而保證整條鏈路上請求的原子性。
復合命令
由于Redis命令本身的限制，有些業務方反饋實現一個功能，比如對hash key進行超時處理需要進行2次操作，一次設置值，一次設置超時。雖然中間件將這層邏輯封裝之后對外只提供一個api，但內部執行仍然是2個命令，可能存在原子性問題。TRocks針對這種情況增加了一些復合功能的命令，調用這些命令可以實現相同的效果并保證原子性，同時這些功能對用戶是透明的，直接調用客戶端相應api即可使用。
2、可用性增強
可調一致性
Kvrocks本身的主從復制邏輯與Redis相似，都是通過異步方式進行的。在這種方式下，如果出現網絡斷開或者master宕機，數據還未來得及同步，就會出現數據丟失的情況。為了避免此類問題，TRocks加入了類似Mysql的半同步復制來提高數據的一致性。我們可以通過打開半同步方式并指定至少需要參與的半同步slave的數量來啟用該功能，提高災備能力。
例如一個1主4從的集群，設定需要等待任意2臺Slave響應。
如圖3所示，當滿足響應的slave為2的時候，半同步即可認為完成，即使此時另外兩臺slave可能還未完成同步工作。
但這種方式在多機房部署的情況仍然可能存在問題。因為距離的關系，相同機房的數據傳輸速率會更高，所以master復制到和其在同一個機房的slave通常情況會更快(圖4)。
這樣就很容易發生同機房的slave數據復制的進度要快于異地機房的slave。如果發生機房級的故障，導致master所在集群的服務全都無法正常工作，這個時候就可能發生數據丟失。
為此我們在半同步復制的基礎上增加了IDC模式，使得即使初始條件已經滿足，也需要至少存在相關IDC的slave反饋才能完成整個復制流程。IDC模式有兩種，本地復制和異地復制。
以異地模式為例，如果返回slave的數量滿足條件，且包含至少一臺來自于master所在機房不同的slave，則半同步復制完成。如果當前響應中未包含非master集群的slave，則繼續等待，直到master接收到一臺來自異地的slave的反饋，半同步才能完成(圖5)。
盡管異地模式數據的安全性更高，但也會影響整個系統的性能，這個性能差正常情況下取決于不同機房之間的網絡延遲。基于對性能和數據可用性的不同要求，使用方可以酌情選擇全異步復制(即關閉半同步)，半同步 & 半同步(本地)復制或者半同步(異地)復制。
全量同步復制抑制
上面說到異步復制在異常情況下可能存在數據缺失的情況，如果再加上運維系統對主從關系的調整，就會發生數據沖突。而我們目前TRocks的版本還在快速迭代中，希望每次升級版本能夠對用戶透明，然而事實并非如此。
假設存在master A和slave B，正常情況下A和B的數據是保持一致的(綠色部分)，但當A發生宕機的時候，B可能還未同步到A的最新數據，這時B的數據不再增加。但隨后哨兵發現master無法訪問，就把B提升為master并開始處理寫入數據(藍色部分)。當一段時間后，A系統恢復，重新加入進集群，此時A會變為masterB的slave，并嘗試從B中同步數據，這里就可能存在沖突區(圖6)。
按照Kvrocks初始的復制邏輯，A會認為自身數據存在問題，并放棄全部數據然后從頭開始進行全量同步B的數據。這個行為本身沒有問題。然而實際生產環境下，如果數據量很大的話，全量同步的耗時會比較長，而硬盤相比內存的帶寬至少小兩個數量級，因為我們的實例都是容器化部署，這有可能導致災難性的后果，A在同步數據的時候會產生大量的IO，從而可能會影響A/B所在的宿主機上的所有的實例。
在數據一致性要求沒有那么高的場景中，僅僅因為可能的幾條數據不一致就重新同全量同步，代價非常昂貴。所以我們希望在非強一致性條件下，系統可以容忍極少量的數據差異，盡可能避免全量同步以便充分利用資源。
我們的方案是當檢測到數據不一致的時候，主從之間會進行交互協調，計算出沖突區的范圍，并從沖突區之后第一條數據開始進行同步。為什么不是直接從沖突區后面開始同步?這里需要有個概念，TRocks/Kvrocks的數據都是追加形式的，增刪改都會在log文件中追加一條記錄，并提供起始位置(Sequence)，對應不同的Redis類型的記錄會有不同的長度(Count)，比如一條SET指令對應的Sequence會累加1，而HSET指令會累加2。
從Sequence到Sequence+Count就是一條記錄的數據范圍。當重新同步的時候，沖突區的結束位置如果處于正常數據的中間，這樣是沒有辦法取得完整數據的，所以需要從沖突區后第一條數據開始。
而沖突區與同步開始之間的區域是補足區(圖7)，我們通過插入空白數據來進行填補，所以對于A和B來說，他們之間不一致區域是沖突區和補足區的總和。而對于沖突的部分，我們會記錄下兩邊的差異，真有差異發生時，參考git解決沖突的思路，將數據的選擇權交給用戶。
上線該feature后，版本的升級就變得比較輕松，大部分情況下版本升級只是一次實例的拉出重啟拉入，實例也是秒級up，升級過程也基本上對業務做到了透明。
在解決此問題的同時，我們也注意到master/slave數據是對齊的某些情況下也會發生全量同步，檢查下來發現是pub/sub命令的問題。
這個命令是哨兵用于訂閱服務消息的，但Kvrocks的pub/sub是一個寫操作，這樣就會造成持續性的數據寫入從而累加rocksdb的Sequence，這樣如果一個slave宕機后恢復，還沒來得及與master同步卻被哨兵寫入了一條無關緊要的pub消息，累加了Seq從而觸發了不必要的全量同步，但實際上該功能并非必須，所以我們修改Kvrocks處理哨兵pubsub消息的規則，不去寫之后這個命令只工作在內存中，自然不會累加rocksdb的Sequence，杜絕這種情況全量同步的可能性。
3、運維治理能力增強
水平擴縮容
在之前的Redis治理演進之路文章中，我們介紹了一種新的擴縮容方案來解決Redis集群版本升級和擴縮容的問題(圖8)，參考同樣的思路，我們繼續改造BinlogServer來實現TRocks的集群的水平擴縮容，這套方案實際上不僅解決了擴縮容的問題，同時也解決了Redis到Redis的數據遷移，TRocks到TRocks的數據遷移，Redis與TRocks之間的互相遷移，也可以幫助用戶平滑的從Redis的訪問過渡到TRocks的訪問。
然而相比Redis擴縮容基本不需要考慮內存帶寬，硬盤帶寬太窄，而數據遷移的時候流量太大。由于所有數據最終都需要在新集群上刷盤，導致遷移過程中目標集群的磁盤讀寫會非常大，又由于我們都是容器化部署，大量的磁盤讀寫也可能會影響到統一宿主機上的其他無關的應用，所以我們調整了TRocks的寫入限流設置，以避免大量寫入影響磁盤性能，同時修改了BinlogServer加入了限流功能，平緩數據傳輸的速率。
哨兵多機房部署
為了保證TRocks集群可以跨機房容災，哨兵需要部署在多個機房中，目前我們是三機房部署。如下圖(圖9)：
在部署的時候，遇到了一個問題，我們發現哨兵之間經常無法選出leader，需要等下一個選舉周期(6分鐘)才能重新選出，導致長時間無法確定TRocks master。這個問題本身跟TRocks沒有太大關系，只是實際使用中對我們故障處理帶來了不小麻煩。
出現無法選出leader的原因是多個哨兵同時發起選舉希望成為leader，導致最終每個哨兵都選擇了自己，無法達成共識。查看源碼發現官方已經為發起選舉前設置了隨機的間隔時間(50~100ms)，但實際操作中發現這個隨機間隔反而增加了發生選角失敗的可能，考慮應該是隨機時間太短導致，所以我們將隨件間隔修改為100~200ms，同時在哨兵發現master宕機之后就立即發起選舉來盡可能規避無法選主的問題。
五、一些數據
1、性能數據
TRocks在內網上線后，在各個業務線都得到了廣泛的使用，排除公有云的部分，私有云上已經有將近2K的實例，10T+的數據量，下圖(圖10，圖11)可以看到同樣的數據寫TRocks和Redis的性能對比。平均響應時間，99.9%在同一個水平，并且我們還可以看到，得益于自定義的命令，同樣的功能相比Redis更加簡潔。
根據我們跟業務方壓測，一臺40C和2塊RAID0的SATA SSD在保證良好響應的前提下(99.9%<10ms)約能提供讀寫的QPS為8-10W，其中value<1k。而如果換成NVME SSD這個QPS可以提升3-5倍。
2、成本數據
假設TRocks都是容器化部署，并且一臺40C的宿主機上可以部署20個實例，每個實例大小為40G，因為TRocks相比Redis有不小的壓縮功能(約3-7倍的壓縮率)，如果將Redis的數據導過來可以平穩運行，那么TRocks相比Redis約可以節約90%的成本。
既然能省這么多成本，是否所有的Redis都可以用TRocks來代替，我們是否需要將私有云上所有的Redis都替換成為TRocks?
答案都是否定的，也不是我們推廣TRocks的初衷，原因有以下兩點：
- 如上文所提到的，我們希望TRocks能擁有Redis的大部分能力，而又不僅僅局限于Redis，希望它更是一個通用的KV數據庫，能提供更多樣化的能力來支撐業務的訴求。
- 硬盤的帶寬與內存有2個數量級的差距，而這些先天不足也無法滿足某些Redis場景的需求。比如大Key(>100K)響應和Redis還是有一定的差距，此外某些數據量小并且單個實例訪問QPS較高的實例，用TRocks來替換也并不合適，因為規模化運維治理，我們需要考慮整個宿主機和每個實例是否能平穩運行，一般來說單個實例>10G，QPS<5K 是比較適合的。當然NVME SSD可以極大縮短大Key的響應時間和提升單個實例QPS的上限。
六、未來規劃
1、復合命令增強
我們調研發現，業務經常為了獲取一條數據，需要多次查詢TRocks，類似二度人脈的取數據邏輯，多次的網絡IO會導致耗時增加，而設計通用的命令來支持業務需求，減少網絡IO變得非常重要，此外還有些用戶詢問TRocks的hash類型中的subkey是否也可以實現過期。由于hash功能目前仍然是遵照Redis的規則，所以現在是按照整個hash key一起過期而不能實現內部數據項的過期。這個需求是有一定價值的，未來我們會通過提供一個特殊的hash結構來實現此類功能。
2、引入checkpoint
Kvrocks1.X在進行全量復制時，master會生成硬的backup，會拷貝文件產生大量的IO，而官方2.0版本已經用Rocksdbcheckpoint解決了這個問題，我們也已經將2.0版本merge過來測試，準備適時升級上線。
3、使用NVME SSD
目前攜程的大量TRocks還是跑在SATA接口的SSD上，而據我們的測試下來兩塊SATA raid0的帶寬大約為800MB/S，導致硬盤非常容易跑滿，相比之下，NVME SSD的帶寬基本都是幾G起步，并且我們測試下來NVME SSD在小的壓力下，對于SATA SSD性能有3-5倍的提升，而對于大Key的情況(超過100K)和大的壓力下，NVME SSD的性能提升可以高達10-100倍。因此我們已經計劃將SATA SSD全換成NVME SSD，進一步提升TRocks的性能。
