作者 ｜ NoSQL team

背景

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

Abase 作為一款由字節(jié)跳動完全自研的高性能、大容量、高可用的 KV 存儲系統(tǒng)，支撐了業(yè)務(wù)不斷快速增長的需求。但隨著公司的持續(xù)發(fā)展，業(yè)務(wù)數(shù)量、規(guī)模持續(xù)快速增長，我們業(yè)務(wù)對系統(tǒng)也提出了更高的要求，比如：

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

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

CRDT 支持：確保多寫架構(gòu)下的數(shù)據(jù)能自動解決沖突問題，達(dá)成最終一致;

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

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

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

在此背景下，Abase 團(tuán)隊于 2019 年年底開始孵化第二代 Abase 系統(tǒng)。結(jié)合業(yè)界的先進(jìn)架構(gòu)方案及公司內(nèi)部實踐過程中的積累和思考，團(tuán)隊推出了資源池化，支持多租戶、多寫、CRDT 的軟硬件一體化設(shè)計的新一代 NoSQL 數(shù)據(jù)庫 —— Abase2。

架構(gòu)概覽

數(shù)據(jù)模型

Abase 支持 Redis 的幾種主要數(shù)據(jù)結(jié)構(gòu)與相應(yīng)接口：

String: 支持 Set、Append、IncrBy，是字節(jié)線上使用最為廣泛的數(shù)據(jù)模型;

Hash/Set：使用率僅次于 String，在部分更新/查詢的結(jié)構(gòu)化數(shù)據(jù)存取場景中廣泛使用;

ZSet: 廣泛應(yīng)用于榜單拉鏈等在線業(yè)務(wù)場景，區(qū)別于直接使用 String+Scan 方式進(jìn)行包裝，Abase 在 ZSet 結(jié)構(gòu)中做了大量優(yōu)化，從設(shè)計上避免了大量 ZIncrBy 造成的讀性能退化;

List/TTLQueue: 隊列接口語義使業(yè)務(wù)在對應(yīng)場景下非常方便地接入。

架構(gòu)視圖

圖 1：Abase2 整體架構(gòu)圖

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

RootServer

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

MetaServer

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

管理元信息的邏輯視圖：包括 Namespace，Table，Partition，Replica 等狀態(tài)和配置信息以及之間的關(guān)系;

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

多租戶 QoS 總控，在異構(gòu)機器的場景下根據(jù)各個租戶與機器的負(fù)載進(jìn)行副本 Balance 調(diào)度;

故障檢測，節(jié)點的生命管理，數(shù)據(jù)可靠性跟蹤，在此基礎(chǔ)上進(jìn)行節(jié)點的下線和數(shù)據(jù)修復(fù)。

圖 2: 集群物理視圖

圖 3: 集群邏輯視圖

DataNode

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

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

圖 4：DataNode 資源視角

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

Replica 核心模塊如下圖所示，整個 Partition 為 3 層結(jié)構(gòu)：

數(shù)據(jù)模型層：如上文提到的 String, Hash 等 Redis 生態(tài)中的各類數(shù)據(jù)結(jié)構(gòu)接口。

一致性協(xié)議層：在多主架構(gòu)下，多點寫入勢必會造成數(shù)據(jù)不一致，Anti-Entropy 一方面會及時合并沖突，另一方面將協(xié)調(diào)沖突合并后的數(shù)據(jù)下刷至引擎持久化層并協(xié)調(diào) WAL GC。

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

圖 5: Replica 分層架構(gòu)

Client/Proxy/SDK

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

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

DTS (Data Transfer Service)

DTS 主導(dǎo)了 Abase 生態(tài)系統(tǒng)的發(fā)展，在一二代透明遷移、備份回滾、Dump、訂閱等諸多業(yè)務(wù)場景中起到了非常核心的作用，由于篇幅限制，本文不做更多的詳細(xì)設(shè)計敘述。

關(guān)鍵技術(shù)

一致性策略

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

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

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

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

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

讀寫流程

下面我們將詳細(xì)介紹在多主模型下 Abase 的數(shù)據(jù)讀寫流程以及數(shù)據(jù)最終一致的實現(xiàn)方案。

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

對于寫請求，Proxy 將請求轉(zhuǎn)發(fā)到合適的 Replica 上，Replica Coordinator 將寫請求序列化后并發(fā)地發(fā)送至所有 Replica，并根據(jù)一致性策略決定請求成功所需要的最少成功響應(yīng)數(shù) W?？捎眯耘c W 成反比，W=1 時可獲得最大的寫可用性。

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

在單個副本內(nèi)，數(shù)據(jù)首先寫入到 WAL 內(nèi)，保證數(shù)據(jù)的持久化，然后提交到引擎數(shù)據(jù)暫存層。引擎在達(dá)到一定條件后將緩存數(shù)據(jù)下刷到持久化存儲，然后 WAL 對應(yīng)數(shù)據(jù)即可被 GC。

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

圖 6: 寫流程示意圖

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

Anti-Entropy

由上述寫流程可以看到，當(dāng) W<N時，部分副本寫入成功即可認(rèn)為請求成功，而由于網(wǎng)絡(luò)抖動等原因數(shù)據(jù)可能并未在所有副本上達(dá)成一致狀態(tài)，我們通過 Anti-Entropy 機制異步地完成數(shù)據(jù)一致性修復(fù)。

為了便于檢測分片各個 Replica 間的數(shù)據(jù)差異，我們在 WAL 之上又構(gòu)建了一層 ReplicaLog(索引)，每個 Replica 都對應(yīng)一個由自己負(fù)責(zé)的 ReplicaLog，并會在其他 Replica 上創(chuàng)建該 ReplicaLog 的副本，不同 Replica 接收的寫請求將寫到對應(yīng)的 ReplicaLog 內(nèi)，并分配唯一嚴(yán)格遞增的 LogID，我們稱為 Seqno。

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

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

另外，正常情況下副本間數(shù)據(jù)能做到秒級達(dá)成一致，因此 ReplicaLog 通常只需要構(gòu)建在內(nèi)存中，消耗極少的內(nèi)存，即可達(dá)到數(shù)據(jù)一致的目的。在極端情況下(如網(wǎng)絡(luò)分區(qū))，ReplicaLog 將被 dump 到持久化存儲以避免 ReplicaLog 占用過多內(nèi)存。

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

沖突解決

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

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

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

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

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

在實踐中我們發(fā)現(xiàn)，上述方式存在幾個問題：

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

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

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

圖 7：數(shù)據(jù)暫存層基本結(jié)構(gòu)示意圖

CRDTs

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

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

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

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

圖 8：Operation-based CRDT 數(shù)據(jù)合并示意圖

完整 CRDT 的實現(xiàn)算法和工程優(yōu)化細(xì)節(jié)我們將在后續(xù) Abase2 介紹文章中詳細(xì)說明。

全球部署

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

圖 9: 多數(shù)據(jù)中心部署

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

多租戶 QoS

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

圖 11：資源池分類示意圖

在資源池內(nèi)的多租戶混部要解決兩個關(guān)鍵問題：

1、DataNode 的 QoS 保障

DataNode 將請求進(jìn)行分類量化：

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

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

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

如上圖所示，用戶請求在抵達(dá)租戶服務(wù)層之前需要邁過兩道關(guān)卡：

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

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

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

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

2、多租戶的負(fù)載均衡

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

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

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

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

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

圖 14(1): 某集群均衡調(diào)度前的負(fù)載分布

圖 14(2): 某集群均衡調(diào)度后的負(fù)載分布

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

現(xiàn)狀與規(guī)劃

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

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

技術(shù)先進(jìn)性：在自研多寫架構(gòu)上做更多探索，通過支持 RDMA/io_uring/ZNS SSD/PMEM 等新硬件新技術(shù)，讓 Abase2 的各項指標(biāo)更上一個臺階。

易用性：建設(shè)標(biāo)準(zhǔn)的云化產(chǎn)品，提供 Serverless 服務(wù)，和更自動的冷熱沉降，更完善的 Redis 協(xié)議兼容，更高魯棒性的 dump/bulkload 等功能。

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

結(jié)語

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