作者 ｜ NoSQL team

背景

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

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

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

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

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

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

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

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

在此背景下，Abase 團(tuán)隊(duì)于 2019 年年底開(kāi)始孵化第二代 Abase 系統(tǒng)。結(jié)合業(yè)界的先進(jìn)架構(gòu)方案及公司內(nèi)部實(shí)踐過(guò)程中的積累和思考，團(tuán)隊(duì)推出了資源池化，支持多租戶、多寫(xiě)、CRDT 的軟硬件一體化設(shè)計(jì)的新一代 NoSQL 數(shù)據(jù)庫(kù) —— 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ù)存取場(chǎng)景中廣泛使用;

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

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

架構(gòu)視圖

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

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

RootServer

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

MetaServer

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

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

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

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

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

圖 2: 集群物理視圖

圖 3: 集群邏輯視圖

DataNode

DataNode 是數(shù)據(jù)存儲(chǔ)節(jié)點(diǎn)。部署時(shí)，可以每臺(tái)機(jī)器或者每塊盤(pán)部署一個(gè) DataNode，為方便隔離磁盤(pán)故障，線上實(shí)際采用每塊盤(pán)部署一個(gè) DataNode 的方式。

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

圖 4：DataNode 資源視角

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

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

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

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

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

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

Client/Proxy/SDK

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

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

DTS (Data Transfer Service)

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

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

一致性策略

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

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

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

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

未來(lái)也會(huì)提供更多的一致性選擇，來(lái)滿足用戶的不同需求。

讀寫(xiě)流程

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

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

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

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

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

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

圖 6: 寫(xiě)流程示意圖

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

Anti-Entropy

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

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

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

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

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

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

沖突解決

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

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

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

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

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

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

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

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

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

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

CRDTs

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

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

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

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

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

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

全球部署

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

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

圖 10: 邊緣-中心機(jī)房部署

多租戶 QoS

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

圖 11：資源池分類示意圖

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

1、DataNode 的 QoS 保障

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

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

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

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

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

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

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

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

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

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

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

• 同一個(gè)租戶的 Replica 盡量分散，確保租戶 Quota 可快速擴(kuò)容;
• 不會(huì)因?yàn)閭€(gè)別慢節(jié)點(diǎn)阻塞整體均衡流程;

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

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

• 根據(jù)近期的 QPS 與磁盤(pán)空間使用率的最大值，為每個(gè) Core 構(gòu)建二維負(fù)載向量;
• 計(jì)算全局最優(yōu)二維負(fù)載向量，即資源池中所有 Core 負(fù)載向量在兩個(gè)維度上的平均值;
• 將高負(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ù)載分布散點(diǎn)圖，其中：紅點(diǎn)是最優(yōu)負(fù)載向量，橫縱分別表示 Core 負(fù)載向量的第一和第二維度，每個(gè)點(diǎn)對(duì)應(yīng)一個(gè) Core。從圖可以看出，各個(gè) Core 的負(fù)載向量基本以最優(yōu)負(fù)載向量為中心分布。

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

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

未來(lái)的 Abase2 會(huì)持續(xù)向著下面幾個(gè)方向努力，我們的追求是

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

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

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

結(jié)語(yǔ)

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