作者 ｜ NoSQL team

背景

自 2016 年以來，為了支撐在線推薦的存儲需求而誕生的——字節跳動自研高可用 KV 存儲 Abase，逐步發展成支撐包括推薦、廣告、搜索、抖音、西瓜、飛書、游戲等公司內幾乎所有業務線的 90% 以上的 KV 存儲場景，已成為公司內使用最廣泛的在線存儲系統之一。

Abase 作為一款由字節跳動完全自研的高性能、大容量、高可用的 KV 存儲系統，支撐了業務不斷快速增長的需求。但隨著公司的持續發展，業務數量、規模持續快速增長，我們業務對系統也提出了更高的要求，比如：

極致高可用：相對于一致性，信息流等業務對可用性要求更高，希望消除宕機選主造成的短時間不可用，和慢節點問題;

全球部署：無論是邊緣機房還是不同地域的機房，同一個 Abase2 集群的用戶都可以就近訪問，獲取極快的響應延遲;

CRDT 支持：確保多寫架構下的數據能自動解決沖突問題，達成最終一致;

更低成本：通過資源池化解決不同用戶資源使用不均衡，造成資源利用率不足問題，降低成本;

極致高性能：相同的資源使用下，要求提供盡可能高的寫/讀吞吐，和較低的訪問延遲。適配 IO 設備和 CPU 性能發展速度不匹配趨勢，極致高效對 CPU 的使用;

兼容 Redis 協議：為了讓 Redis 用戶可以無障礙的接入 Abase，以滿足更大容量的存儲需求，我們需要完全兼容 Redis 協議。

在此背景下，Abase 團隊于 2019 年年底開始孵化第二代 Abase 系統。結合業界的先進架構方案及公司內部實踐過程中的積累和思考，團隊推出了資源池化，支持多租戶、多寫、CRDT 的軟硬件一體化設計的新一代 NoSQL 數據庫 —— Abase2。

架構概覽

數據模型

Abase 支持 Redis 的幾種主要數據結構與相應接口：

String: 支持 Set、Append、IncrBy，是字節線上使用最為廣泛的數據模型;

Hash/Set：使用率僅次于 String，在部分更新/查詢的結構化數據存取場景中廣泛使用;

ZSet: 廣泛應用于榜單拉鏈等在線業務場景，區別于直接使用 String+Scan 方式進行包裝，Abase 在 ZSet 結構中做了大量優化，從設計上避免了大量 ZIncrBy 造成的讀性能退化;

List/TTLQueue: 隊列接口語義使業務在對應場景下非常方便地接入。

架構視圖

圖 1：Abase2 整體架構圖

Abase2 的整體架構主要如上圖所示，在用戶、管控面、數據面三種視角下主要包含 5 組核心模塊。

RootServer

線上一個集群的規模大約為數千臺機器，為管理各個集群，我們研發了 RootServer 這個輕量級組件。顧名思義，RootServer 擁有全集群視角，它可以更好地協調各個集群之間的資源配比，支持租戶在不同集群之間的數據遷移，提供容災視圖并合理控制爆炸半徑。

MetaServer

Abase2 是多租戶中心化架構，而 MetaServer 則是整個架構的總管理員，它主要包括以下核心功能：

管理元信息的邏輯視圖：包括 Namespace，Table，Partition，Replica 等狀態和配置信息以及之間的關系;

管理元信息的物理視圖：包括 IDC，Pod，Rack，DataNode，Disk，Core 的分布和 Replica 的位置關系;

多租戶 QoS 總控，在異構機器的場景下根據各個租戶與機器的負載進行副本 Balance 調度;

故障檢測，節點的生命管理，數據可靠性跟蹤，在此基礎上進行節點的下線和數據修復。

圖 2: 集群物理視圖

圖 3: 集群邏輯視圖

DataNode

DataNode 是數據存儲節點。部署時，可以每臺機器或者每塊盤部署一個 DataNode，為方便隔離磁盤故障，線上實際采用每塊盤部署一個 DataNode 的方式。

DataNode 的最小資源單位是 CPU Core(后簡稱 Core)，每個 Core 都擁有一個獨立的 Busy Polling 協程框架，多個 Core 共享一塊盤的空間與 IO 資源。

圖 4：DataNode 資源視角

一個 Core 包含多個 Replica，每個 Replica 的請求只會在一個 Core 上 Run-to-Complete，可以有效地避免傳統多線程模式中上下文切換帶來的性能損耗。

Replica 核心模塊如下圖所示，整個 Partition 為 3 層結構：

數據模型層：如上文提到的 String, Hash 等 Redis 生態中的各類數據結構接口。

一致性協議層：在多主架構下，多點寫入勢必會造成數據不一致，Anti-Entropy 一方面會及時合并沖突，另一方面將協調沖突合并后的數據下刷至引擎持久化層并協調 WAL GC。

數據引擎層：數據引擎層首先有一層輕量級數據暫存層(或稱 Conflict Resolver)用于存儲未達成一致的數據;下層為數據數據引擎持久化層，為滿足不同用戶多樣性需求，Abase2 引設計上采用引擎可插拔模式。對于有順序要求的用戶可以采用 RocksDB，TerarkDB 這類 LSM 引擎，對于無順序要求點查類用戶采用延遲更穩定的 LSH 引擎。

圖 5: Replica 分層架構

Client/Proxy/SDK

Client 模塊是用戶側視角下的核心組件，向上提供各類數據結構的接口，向下一方面通過 MetaSync 與 MetaServer 節點通信獲取租戶 Partition 的路由信息，另一方面通過路由信息與存儲節點 DataNode 進行數據交互。此外，為了進一步提高服務質量，我們在 Client 的 IO 鏈路上集成了重試、Backup Request、熱 Key 承載、流控、鑒權等重要 QoS 功能。

結合字節各類編程語言生態豐富的現狀，團隊基于 Client 封裝了 Proxy 組件，對外提供 Redis 協議(RESP2)與 Thrift 協議，用戶可根據自身偏好選擇接入方式。此外，為了滿足對延遲更敏感的重度用戶，我們也提供了重型 SDK 來跳過 Proxy 層，它是 Client 的簡單封裝。

DTS (Data Transfer Service)

DTS 主導了 Abase 生態系統的發展，在一二代透明遷移、備份回滾、Dump、訂閱等諸多業務場景中起到了非常核心的作用，由于篇幅限制，本文不做更多的詳細設計敘述。

關鍵技術

一致性策略

我們知道，分布式系統難以同時滿足強一致性、高可用性和正確處理網絡故障(CAP )這三種特性，因此系統設計者們不得不做出權衡，以犧牲某些特性來滿足系統主要需求和目標。比如大多數數據庫系統都采用犧牲極端情況下系統可用性的方式來滿足數據更高的一致性和可靠性需求。

Abase2 目前支持兩種同步協議來支持不同一致性的需求：

多主模式(Multi-Leader)：相對于數據強一致性，Abase 的大多數使用者們則對系統可用性有著更高的需求，Abase2 主要通過多主技術實現系統高可用目標。在多主模式下，分片的任一副本都可以接受和處理讀寫請求，以確保分片只要有任一副本存活，即可對外提供服務。同時，為了避免多主架構按序同步帶來的一些可用性降低問題， 我們結合了無主架構的優勢，在網絡分區、進程重啟等異常恢復后，并發同步最新數據和老數據。此外，對于既要求寫成功的數據要立即讀到，又不能容忍主從切換帶來的秒級別不可用的用戶，我們提供無更新場景下的寫后讀一致性給用戶進行選擇。實現方式是通過 Client 配置 Quorum 讀寫(W+R>N)，通常的配置為 W=3，R=3，N=5。

單主模式(Leader&Followers)：Abase2 支持與一代系統一樣的主從模式，并且，半同步適合于對一致性有高要求，但可以忍受一定程度上可用性降低的使用場景。與 MySQL 半同步類似。系統將選擇唯一主副本，來處理用戶的讀寫請求，保證至少 2 個副本完成同步后，才會通知用戶寫入成功。以保證讀寫請求的強一致性，并在單節點故障后，新的主節點仍然有全量數據。

未來也會提供更多的一致性選擇，來滿足用戶的不同需求。

讀寫流程

下面我們將詳細介紹在多主模型下 Abase 的數據讀寫流程以及數據最終一致的實現方案。

對于讀請求，Proxy 首先根據元信息計算出請求對應的分片，再根據地理位置等信息將請求轉發到該分片某一個合適的 Replica 上，Replica Coordinator 根據一致性策略查詢本地或遠端存儲引擎后將結果按照沖突解決規則合并后返回給 Proxy，Proxy 根據對應協議將結果組裝后返回給用戶。

對于寫請求，Proxy 將請求轉發到合適的 Replica 上，Replica Coordinator 將寫請求序列化后并發地發送至所有 Replica，并根據一致性策略決定請求成功所需要的最少成功響應數 W。可用性與 W 成反比，W=1 時可獲得最大的寫可用性。

如圖 6 所示，假設分片副本數 N=3，當用戶寫請求到達 Proxy 后，Proxy 根據地理位置等信息將請求轉發到分片的某一個副本(Replica B)，Replica B 的 Coordinator 負責將請求寫入到本地，且并發地將請求 forward 到其他 Replica，當收到成功寫入的響應數大于等于用戶配置的 W 時(允許不包括本地副本)，即可認為請求成功，若在一定時間內(請求超時時間)未滿足上述條件，則認為請求失敗。

在單個副本內，數據首先寫入到 WAL 內，保證數據的持久化，然后提交到引擎數據暫存層。引擎在達到一定條件后將緩存數據下刷到持久化存儲，然后 WAL 對應數據即可被 GC。

一個 Core 內所有 Replica 共享一個 WAL，可以盡量合并不同 Replica 的碎片化提交，減少 IO 次數。引擎層則由 Replica 獨占，方便根據不同業務場景對引擎層做精細化配置，同時也便于數據查詢、GC 等操作。

圖 6: 寫流程示意圖

用戶可以根據一致性、可用性、可靠性與性能綜合考慮 NWR 的配比，W(R)為 1 時可獲得最大的寫(讀)可用性與性能;調大 W/R 則可在數據一致性和可靠性方面取得更好的表現。

Anti-Entropy

由上述寫流程可以看到，當 W<N時，部分副本寫入成功即可認為請求成功，而由于網絡抖動等原因數據可能并未在所有副本上達成一致狀態，我們通過 Anti-Entropy 機制異步地完成數據一致性修復。

為了便于檢測分片各個 Replica 間的數據差異，我們在 WAL 之上又構建了一層 ReplicaLog(索引)，每個 Replica 都對應一個由自己負責的 ReplicaLog，并會在其他 Replica 上創建該 ReplicaLog 的副本，不同 Replica 接收的寫請求將寫到對應的 ReplicaLog 內，并分配唯一嚴格遞增的 LogID，我們稱為 Seqno。

每個 Replica 的后臺 Anti-Entropy 任務將定期檢查自身與其他 Replica 的 ReplicaLog 的進度，以確定自身是否已經擁有全部數據。流程如下：

• 獲取自身 ReplicaLog 進度向量[Seqno1, Seqno2..., SeqnoN];
• 與其他 Replica 通信，獲取其他 Replica 的進度向量;
• 比對自身與其他 Replica 進度向量，是否有 ReplicaLog 落后于其他 Replica，如果是則進入第 4 步，否則進入第 5 步;
• 向其他 Replica 發起數據同步請求，從其他 Replica 拉取缺少的 ReplicaLog 數據，并提交到引擎層
• 若已就某 ReplicaLog 在 SeqnoX 之前已達成一致，回收 SeqnoX 之前的 ReplicaLog 數據。

另外，正常情況下副本間數據能做到秒級達成一致，因此 ReplicaLog 通常只需要構建在內存中，消耗極少的內存，即可達到數據一致的目的。在極端情況下(如網絡分區)，ReplicaLog 將被 dump 到持久化存儲以避免 ReplicaLog 占用過多內存。

與 DynamoDB、Cassandra 等通過掃描引擎層構建 merkle tree 來完成一致性檢測相比，Abase 通過額外消耗少量內存的方式，能更高效的完成數據一致性檢測和修復。

沖突解決

多點寫入帶來可用性提升的同時，也帶來一個問題，相同數據在不同 Replica 上的寫入可能產生沖突，檢測并解決沖突是多寫系統必須要處理的問題。

為了解決沖突，我們將所有寫入數據版本化，為每次寫入的數據分配一個唯一可比較的版本號，形成一個不可變的數據版本。

Abase 基于 Hybrid Logical Clock 算法生成全局唯一時間戳，稱為 HLC timestamp，并使用 HLC timestamp 作為數據的版本號，使得不同版本與時間相關聯，且可比較。

通過業務調研，我們發現在發生數據沖突時，大部分業務希望保留最新寫入的數據，部分業務自身也無法判斷哪個版本數據更有意義(復雜的上下游關系)，反而保留最新版本數據更簡潔也更有意義，因此 Abase 決定采用 Last Write Wins 策略來解決寫入沖突。

在引擎層面，最初我們采用 RocksDB 直接存儲多版本數據，將 key 與版本號一起編碼，使得相同 key 的版本連續存儲在一起;查詢時通過 seek 方式找到最新版本返回;同時通過后臺版本合并任務和 compaction filter 將過期版本回收。

在實踐中我們發現，上述方式存在幾個問題：

• 多版本數據通常能在短時間內(秒級)決定哪個版本最終有效，而直接將所有版本寫入 RocksDB，使得即使已經確定了最終有效數據，也無法及時回收無效的版本數據;同時，使用 seek 查詢相比 get 消耗更高，性能更低。
• 需要后臺任務掃描所有版本數據完成無效數據的回收，消耗額外的 CPU 和 IO 資源。
• 引擎層與多版本耦合，使得引擎層無法方便地做到插件化，根據業務場景做性能優化。

為了解決以上問題，我們把引擎層拆分為數據暫存層與通用引擎層，數據多版本將在暫存層完成沖突解決和合并，只將最終結果寫入到底層通用引擎層中。

得益于 Multi-Leader 與 Anti-Entropy 機制，在正常情況下，多版本數據能在很小的時間窗口內決定最終有效數據，因此數據暫存層通常只需要將這個時間窗口內的數據緩存在內存中即可。Abase 基于 SkipList 作為數據暫存層的數據結構(實踐中直接使用 RocksDB memtable)，周期性地將沖突數據合并后寫入底層。

圖 7：數據暫存層基本結構示意圖

CRDTs

對于冪等類命令如 Set，LWW 能簡單有效地解決數據沖突問題，但 Redis String 還需要考慮 Append, Incrby 等非冪等操作的兼容，并且，其它例如 Hash, ZSet 等數據結構則更為復雜。于是，我們引入了 CRDT 支持，實現了 Redis 常見數據結構的 CRDT，包括 String/Hash/Zset/List，并且保持語義完全兼容 Redis。

以 IncrBy 為例，由于 IncrBy 與 Set 會產生沖突，我們發現實際上難以通過 State-based 的 CRDT 來解決問題， 故而我們選用 Operation-based 方案，并結合定期合并 Operation 來滿足性能要求。

為了完全兼容 Redis 語義，我們的做法如下：

• 給所有 Operation 分配全球唯一的 HLC timestamp，作為操作的全排序依據;
• 記錄寫入的 Operation 日志(上文 ReplicaLog)， 每個 key 的最終值等于這些 Operation 日志按照時間戳排序后合并的結果。副本間只要 Operation 日志達成一致，最終狀態必然完全一致;
• 為了防止 Operation 日志過多引發的空間和性能問題，我們定期做 Checkpoint，將達成一致的時間戳之前的操作合并成單一結果;
• 為了避免每次查詢都需要合并 Operation 日志帶來的性能開銷，我們結合內存緩存，設計了高效的查詢機制，將最終結果緩存在 Cache 中，保證查詢過程不需要訪問這些 Operation 日志。

圖 8：Operation-based CRDT 數據合并示意圖

完整 CRDT 的實現算法和工程優化細節我們將在后續 Abase2 介紹文章中詳細說明。

全球部署

結合多主模式，系統可以天然支持全球部署，同時，為了避免網狀同步造成的帶寬浪費，Abase2 在每個地域都可以設置一個 Main Replicator，由它來主導和其它地域間的數據同步。典型的應用場景有多中心數據同步場景以及邊緣計算場景。

圖 9: 多數據中心部署

圖 10: 邊緣-中心機房部署

多租戶 QoS

為了實現資源池化，避免不同租戶間資源獨占造成浪費，Abase2 采用大集群多租戶的部署模式。同時，為了兼顧不同場景優先級的資源隔離需求，我們在集群內部劃分了 3 類資源池，按照不同服務等級進行部署。如圖：

圖 11：資源池分類示意圖

在資源池內的多租戶混部要解決兩個關鍵問題：

1、DataNode 的 QoS 保障

DataNode 將請求進行分類量化：

• 用戶的請求主要歸為 3 類：讀、寫、Scan，三類請求優先級各不相同;
• 不同數據大小的請求會被分別計算其成本，例如一個讀請求的數據量每 4KB 會被歸一化成 1 個讀取單位。

所有的用戶請求都會通過這兩個條件計算出 Normalized Request Cost(NRC)。基于 NRC 我們構建了 Quota 限制加 WFQ 雙層結構的服務質量控制模塊。

圖 12：IO 路徑上的 QoS 示意圖

如上圖所示，用戶請求在抵達租戶服務層之前需要邁過兩道關卡：

• Tenant Quota Gate: 如果請求 NRC 已經超過了租戶對應的配額，DataNode 將會拒絕該請求，保證 DataNode 不會被打垮;
• 分級 Weight Fair Queue: 根據請求類型分發至各個 WFQ，保證各個租戶的請求盡可能地被合理調度。

圖 13(1)：正常狀態延遲

圖 13(2)：突增流量涌入后延遲

如圖 13(2)所示，部分租戶突增流量涌入后(藍綠線)并未對其它租戶造成較大影響。流量突增的租戶請求延遲受到了一定影響，并且出現請求被 Tenant Quota Gate 攔截的現象，而其它租戶的請求調度卻基本不受影響，延遲基本保持穩定。

2、多租戶的負載均衡

負載均衡是所有分布式系統都需要的重要能力之一。資源負載實際上有多個維度， 包括磁盤空間、IO 負載， CPU 負載等。我們希望調度策略能高效滿足如下目標：

• 同一個租戶的 Replica 盡量分散，確保租戶 Quota 可快速擴容;
• 不會因為個別慢節點阻塞整體均衡流程;

最終讓每個機器的各個維度的資源負載百分比接近。

負載均衡流程的概要主要分為 3 個步驟：

• 根據近期的 QPS 與磁盤空間使用率的最大值，為每個 Core 構建二維負載向量;
• 計算全局最優二維負載向量，即資源池中所有 Core 負載向量在兩個維度上的平均值;
• 將高負載 Core 上的 Replica 調度到低負載 Core 上，使高、低負載的 Core 在執行 Replica 調度后，Core 的負載向量與最優負載向量距離變小。

圖 14(1): 某集群均衡調度前的負載分布

圖 14(2): 某集群均衡調度后的負載分布

上圖是線上負載均衡前后各的負載分布散點圖，其中：紅點是最優負載向量，橫縱分別表示 Core 負載向量的第一和第二維度，每個點對應一個 Core。從圖可以看出，各個 Core 的負載向量基本以最優負載向量為中心分布。

現狀與規劃

目前 Abase2 正在逐漸完成對第一代 Abase 系統的數據遷移和升級，使用 Abase2 的原生多租戶能力，我們預計可提升 50%的資源使用率。通過對異地多活架構的改造，我們將為 Abase 用戶提供更加準確、快速的多地域數據同步功能。同時，我們也在為火山引擎上推出 Abase 標準產品做準備，以滿足公有云上用戶的大容量、低成本 Redis 場景需求。

未來的 Abase2 會持續向著下面幾個方向努力，我們的追求是

技術先進性：在自研多寫架構上做更多探索，通過支持 RDMA/io_uring/ZNS SSD/PMEM 等新硬件新技術，讓 Abase2 的各項指標更上一個臺階。

易用性：建設標準的云化產品，提供 Serverless 服務，和更自動的冷熱沉降，更完善的 Redis 協議兼容，更高魯棒性的 dump/bulkload 等功能。

極致穩定：在多租戶的 QoS 實踐和自動化運維等方面不斷追求極致。我們的目標是成為像水和電那樣，讓用戶感覺不到存在的基架產品。

結語

隨著字節跳動的持續發展，業務數量和場景快速增加，業務對 KV 在線存儲系統的可用性與性能的要求也越來越高。在此背景下，團隊從初期的拿來主義演進到較為成熟與完善的 Abase 一代架構。秉持著追求極致的字節范兒，團隊沒有止步于此，我們向著更高可用與更高性能的目標繼續演進 Abase2。由于篇幅限制，更多的細節、優化將在后續文章中重點分期講述。