隨著越來越多企業(yè)將 Kafka 遷移至云原生架構(gòu)，AutoMQ 正逐漸成為 Kafka 用戶的云端優(yōu)選。作為兼容 Apache Kafka 協(xié)議、專為云設(shè)計(jì)的新一代發(fā)行版，AutoMQ 憑借高性能、彈性擴(kuò)展和極致成本等優(yōu)勢，在全球范圍內(nèi)的熱度持續(xù)攀升，GitHub Star 數(shù)也順勢突破 8k 大關(guān)。在海外社區(qū)涌現(xiàn)的眾多討論與推文中，我們發(fā)現(xiàn)了這樣一篇來自開發(fā)者的深度好文，將其內(nèi)容翻譯并呈現(xiàn)給大家，概述如下。

Apache Kafka 雖已成為流數(shù)據(jù)領(lǐng)域的事實(shí)標(biāo)準(zhǔn)，但其誕生于 IDC 時代的“存算一體”架構(gòu)在云原生環(huán)境下正顯露疲態(tài)：高昂的跨可用區(qū)（Cross-AZ）流量成本與難以解耦的存算資源，成為企業(yè)數(shù)字化基礎(chǔ)設(shè)施中不可忽視的隱形債務(wù)。伴隨著云存儲技術(shù)的成熟，Diskless Kafka 逐漸成為下一代消息中間件演進(jìn)的必然趨勢。

在這場架構(gòu)變革中，我們不僅將深入剖析 Diskless Kafka 興起的根本原因，更將目光投向目前唯一的開源、成熟的 Diskless Kafka 方案——AutoMQ。以此為切入點(diǎn)，重點(diǎn)探討 Kafka 向基于共享存儲架構(gòu)演進(jìn)的技術(shù)路徑，并將從各個維度深度剖析 Diskless Kafka 設(shè)計(jì)背后的核心權(quán)衡，助您充分理解不同架構(gòu)的優(yōu)劣，從而選擇出真正適合自己的 Kafka 方案。

引 言

自問世以來，Apache Kafka 已確立了其作為分布式消息領(lǐng)域“事實(shí)標(biāo)準(zhǔn)”的地位，支撐著全球無數(shù)企業(yè)的關(guān)鍵業(yè)務(wù)——從微服務(wù)通信到實(shí)時分析，應(yīng)用場景無處不在。

然而，它的架構(gòu)誕生于本地數(shù)據(jù)中心（On-Premise）主導(dǎo)的時代。在那時，服務(wù)器硬件通常需要預(yù)先采購，且網(wǎng)絡(luò)帶寬遠(yuǎn)不及今日。當(dāng)這種設(shè)計(jì)理念被移植到現(xiàn)代云環(huán)境時，弊端便顯露無疑：跨可用區(qū)（Cross-AZ）的網(wǎng)絡(luò)流量成本飆升，且難以實(shí)現(xiàn)計(jì)算與存儲的獨(dú)立擴(kuò)展。

這一現(xiàn)狀正推動著整個行業(yè)向一種全新的范式演進(jìn)：Diskless Kafka。在本文中，我們將首先 Diskless Kafka 趨勢，并盤點(diǎn)市場上現(xiàn)有的解決方案。隨后，我們將重點(diǎn)剖析 AutoMQ——作為業(yè)內(nèi)最早嘗試實(shí)現(xiàn) Diskless Kafka 的先行者之一。

Diskless Kafka vs Apache Kafka

Kafka 誕生于十多年前的 LinkedIn，旨在為生產(chǎn)者（Producer）與消費(fèi)者（Consumer）提供一種高效的解耦手段；雙方均通過 Broker 進(jìn)行交互以傳遞消息。正如前文所述，Kafka 誕生的時代背景具有以下特征：

• 主要依賴本地數(shù)據(jù)中心（IDC），而非云服務(wù)。

• 那時的網(wǎng)絡(luò)帶寬相當(dāng)有限；因此，構(gòu)建系統(tǒng)的標(biāo)準(zhǔn)做法是將計(jì)算與存儲緊密綁定在一起（即存算一體）。

基于上述背景，Kafka 的 Broker 被設(shè)計(jì)為將消息直接持久化存儲在本地磁盤上，并通過 Broker 間的消息復(fù)制機(jī)制來實(shí)現(xiàn)數(shù)據(jù)冗余與高可用性。

這意味著，擴(kuò)容存儲就必須增加機(jī)器節(jié)點(diǎn)。這種機(jī)制迫使用戶即便在現(xiàn)有計(jì)算資源利用率并不高的情況下，也不得不配置額外的 CPU 和內(nèi)存。

除了資源效率低下的問題，Broker 級別的數(shù)據(jù)復(fù)制在云端多可用區(qū)（AZ）部署中還會帶來巨大的、往往被忽視的財務(wù)黑洞。這種成本主要體現(xiàn)在以下兩個方面：

• 生產(chǎn)者流量成本：在一個典型的跨三個可用區(qū)部署的高可用架構(gòu)中，生產(chǎn)者必須將消息發(fā)送給指定分區(qū)的 Leader Broker。如果 Kafka 集群將 Leader 分區(qū)均勻分布在三個可用區(qū)，那么大約有三分之二的情況下，生產(chǎn)者會將消息發(fā)送到位于不同可用區(qū)的 Broker 上（從而產(chǎn)生跨區(qū)流量費(fèi)用）。

• 復(fù)制流量成本：當(dāng) Leader 節(jié)點(diǎn)接收到數(shù)據(jù)后，為了保證數(shù)據(jù)的持久性，必須將其復(fù)制到位于另外兩個可用區(qū)的 Follower 節(jié)點(diǎn)。這一過程會引發(fā)規(guī)模更為龐大的跨可用區(qū)數(shù)據(jù)傳輸，導(dǎo)致同一份消息數(shù)據(jù)產(chǎn)生“二次”網(wǎng)絡(luò)費(fèi)用。

鑒于上述痛點(diǎn)，各類采用全新架構(gòu)設(shè)計(jì)的系統(tǒng)正應(yīng)運(yùn)而生。

Diskless Kafka

盡管 Kafka 存在上述不足，但其 API 無疑已大獲全勝。它不僅是數(shù)據(jù)流領(lǐng)域的行業(yè)標(biāo)準(zhǔn)，更衍生出了一個極為龐大且成熟的生態(tài)系統(tǒng)。

因此，任何廠商若想提供更優(yōu)的替代方案，其首要前提必須是兼容 Kafka。推倒重來去構(gòu)建一套全新的系統(tǒng)并非良策，重構(gòu) Kafka 的存儲層才是更為高效的路徑。

所謂無盤架構(gòu)（Diskless Architecture），指的是一種將所有消息徹底從 Broker 中剝離，并轉(zhuǎn)而全量存儲于對象存儲（Object Storage）的架構(gòu)模式。

這種新模式徹底重塑了 Kafka 兼容系統(tǒng)在云端的運(yùn)作機(jī)制，其帶來的收益不僅立竿見影，更具顛覆性：

成本優(yōu)勢：相比傳統(tǒng) Kafka Broker 所必需的高性能塊存儲，對象存儲的單位容量（Per GB）成本要低整整一個數(shù)量級。

彈性伸縮：Broker 節(jié)點(diǎn)轉(zhuǎn)變?yōu)闊o狀態(tài)的計(jì)算單元，可根據(jù)處理需求靈活進(jìn)行擴(kuò)縮容；與此同時，存儲容量則完全依托于對象存儲，能夠獨(dú)立、自動地進(jìn)行擴(kuò)展。

持久性與可用性：云對象存儲服務(wù)天生具備極高的持久性，并能自動在多個可用區(qū)之間復(fù)制數(shù)據(jù)。這種高可靠性主要得益于糾刪碼（EC）技術(shù)與自動數(shù)據(jù)復(fù)制機(jī)制的結(jié)合，且這些機(jī)制通常天然具備跨多可用區(qū)的能力。由于數(shù)據(jù)保護(hù)的重任已完全下沉由存儲層接管，系統(tǒng)不再需要維護(hù)昂貴且復(fù)雜的 Broker 級數(shù)據(jù)復(fù)制，從而徹底根除了與之伴生的跨可用區(qū)流量難題。

值得特別指出的是，Diskless Kafka 架構(gòu)與 Kafka 分層存儲（KIP-405）所提出的分層架構(gòu)有著本質(zhì)區(qū)別。KIP-405 引入的是一套雙層存儲體系：

• 本地存儲（Broker 本地磁盤）：用于存儲最新的數(shù)據(jù)。

• 遠(yuǎn)程存儲（S3/GCS/HDFS）：用于存儲歷史數(shù)據(jù)。

然而，在這種架構(gòu)下，Broker 無法實(shí)現(xiàn)徹底的無狀態(tài)化，我們前文討論過的種種痛點(diǎn)依然存在。

從 WarpStream、BufStream 到 Aiven，各路廠商紛紛基于這一理念推出了 Kafka 的替代方案。這類平臺的集中爆發(fā)，恰恰印證了其所解決的痛點(diǎn)是何等關(guān)鍵。雖然它們殊途同歸，都致力于通過對象存儲來實(shí)現(xiàn)降本與彈性增強(qiáng)，但各家的技術(shù)成色與實(shí)現(xiàn)路徑卻不盡相同。

在本文中，我將重點(diǎn)剖析AutoMQ——相較于其他競品，它提供了一種獨(dú)樹一幟的 Diskless Kafka 解法。

AutoMQ

100% Kafka 兼容與開放性

正如我們之前所探討的，新一代系統(tǒng)必須嚴(yán)格遵循 Kafka 協(xié)議。

Kafka 協(xié)議是圍繞本地磁盤構(gòu)建的。從向物理日志追加消息，到通過定位分段文件（Segment Files）中的偏移量（Offset）來服務(wù)消費(fèi)者，所有的操作邏輯都緊緊圍繞著這一設(shè)計(jì)核心。

即便如此，基于對象存儲構(gòu)建 Kafka 兼容方案仍面臨巨大挑戰(zhàn)。暫且不論性能，對象存儲的寫入機(jī)制與磁盤迥異。我們無法像操作文件系統(tǒng)那樣，打開一個不可變對象并直接在末尾追加數(shù)據(jù)。

對此，部分廠商（如 WarpStream、Bufstream）選擇另起爐灶，開發(fā)一套新協(xié)議來兼顧：

• 適配對象存儲

• 提供 Kafka 兼容性

他們認(rèn)為，相較于基于開源 Kafka 協(xié)議進(jìn)行改造，這種方式更為直接。然而，此舉也帶來了嚴(yán)峻挑戰(zhàn)：難以緊跟社區(qū)演進(jìn)的步伐，往往導(dǎo)致某些 Kafka API 特性的支持滯后甚至缺失。例如，WarpStream 就耗費(fèi)了相當(dāng)時日才補(bǔ)齊了對事務(wù)（Transactions）的支持。

AutoMQ 并不認(rèn)可這種路徑。

AutoMQ 選擇了一條不同的路：完整復(fù)用了除存儲層以外的所有 Kafka 上層邏輯。團(tuán)隊(duì)投入了大量精力，為 Kafka 量身打造了一款全新的存儲引擎，它既能與對象存儲無縫對接，又能向上提供 Kafka 協(xié)議運(yùn)行所必需的底層抽象。

得益于此，AutoMQ 有底氣為其 Diskless Kafka 方案承諾 100% 的 Kafka 兼容性；即便 Kafka 社區(qū)后續(xù)推出了諸如隊(duì)列（queues）等前沿新特性，AutoMQ 也能通過合并上游代碼，實(shí)現(xiàn)無縫集成與同步支持。

AutoMQ 的另一大亮點(diǎn)在于其開源屬性。這賦予了用戶極大的自由度——既可以嘗鮮試用，也能在自家環(huán)境中獨(dú)立部署。

放眼當(dāng)下的市場，它是唯一一款兼具開源與生產(chǎn)級可用性的 Diskless Kafka 解決方案。反觀其他開箱即用的競品，無一例外均采用了閉源策略，而 Kafka 社區(qū)官方關(guān)于 Diskless Kafka Topic 的提案（KIP: Diskless Topic）尚處于討論之中，遠(yuǎn)未落地。

絕不以犧牲低延遲為代價

向?qū)ο蟠鎯懭霐?shù)據(jù)的速度，無疑要慢于本地磁盤。一些 Diskless Kafka 方案選擇了犧牲低延遲性能：它們必須等到消息在對象存儲中完成持久化后，才會向生產(chǎn)者返回確認(rèn)（ACK）。

然而，這種方案伴隨著嚴(yán)重的代價。當(dāng)延遲出現(xiàn)數(shù)量級級別的惡化時，客戶端往往需要投入額外的時間重新打磨配置，涵蓋從并發(fā)度到緩存大小的方方面面（關(guān)于緩存，后文會有更多討論）。在金融等對延遲極度敏感的關(guān)鍵業(yè)務(wù)場景中，這種程度的性能退化往往是不可接受的。

AutoMQ 拒絕這種妥協(xié)。

為此，他們借鑒了數(shù)據(jù)庫領(lǐng)域的一個經(jīng)典理念：預(yù)寫日志（Write Ahead Log， WAL）。這是一種專用于崩潰恢復(fù)與事務(wù)恢復(fù)的“僅追加”（Append-only）日志結(jié)構(gòu)。其原理十分簡單：所有的數(shù)據(jù)變更，必須先被完整記錄在日志中，隨后才能被應(yīng)用到數(shù)據(jù)庫的實(shí)際數(shù)據(jù)文件中。

遵循這一原則，即便系統(tǒng)在事務(wù)提交之后、變更尚未刷入數(shù)據(jù)文件之前發(fā)生崩潰，系統(tǒng)依然可以通過讀取 WAL 來重放（Replay）這些變更。這對于數(shù)據(jù)庫管理系統(tǒng)（DBMS）確保數(shù)據(jù)的持久性至關(guān)重要。

回到 AutoMQ 的架構(gòu)設(shè)計(jì)上來，每個 Broker 都配備了一個 WAL，其底層依托于 AWS FSx 或其他云廠商提供的同類高性能存儲服務(wù)。正是憑借這些通常具備跨可用區(qū)復(fù)制能力的強(qiáng)健共享服務(wù)，AutoMQ 能夠確保從容應(yīng)對可用區(qū)（AZ）級別的故障。

當(dāng) Broker 接收到消息時，會先將其寫入內(nèi)存緩沖區(qū)，待數(shù)據(jù)成功持久化至 WAL 后，便立即向生產(chǎn)者返回確認(rèn)響應(yīng)（ACK）。通過這種機(jī)制，客戶端無需等待消息寫入對象存儲（這一相對緩慢的過程），從而顯著降低了延遲。

隨后，這些消息會被打包，通過異步方式批量刷寫（Flush）至對象存儲中。

相較于等待一批消息被完整寫入對象存儲，在消息持久化至 WAL（磁盤）后立即發(fā)送 ACK 響應(yīng)，無疑要快得多。

需要補(bǔ)充說明的一點(diǎn)是，由于磁盤設(shè)備主要承擔(dān) WAL 的職能以確保消息的持久性，系統(tǒng)對磁盤空間的需求極小。AutoMQ 默認(rèn)將 WAL 的大小設(shè)定為 10GB 即可滿足需求。

基于 Leader 與無 Leader 架構(gòu)之爭

究其核心，Apache Kafka 是一個基于 Leader（Leader-Based）的系統(tǒng)。對于 Topic 的每一個分區(qū)，通常都配備了一個 Leader 以及零個或多個 Follower。所有的寫入操作都必須流向該分區(qū)的 Leader，而讀取請求則可以由 Leader 或該分區(qū)的 Follower 來承接。AutoMQ 依然沿用了這一架構(gòu)路線。

在 Diskless Kafka 架構(gòu)下，鑒于所有 Broker 均共享底層的對象存儲，Bufstream 和 WarpStream 等廠商認(rèn)為，傳統(tǒng)的“基于 Leader（Leader-Based）”架構(gòu)已非必需。

相反，他們將所有 Broker 視為一個同構(gòu)的、無狀態(tài)的計(jì)算資源池；也就是說，任意 Broker 均可接收針對任意分區(qū)的寫入請求。業(yè)界通常將這種模式稱為“無 Leader（Leaderless）架構(gòu)”。

接下來，我們將從多個維度深入探討，為您剖析這兩種架構(gòu)設(shè)計(jì)背后的權(quán)衡與取舍。

額外的組件

為了實(shí)現(xiàn)無 Leader 架構(gòu)，相較于原生 Kafka 方案，系統(tǒng)在部署時必須引入一個額外的組件。由于每個 Broker 都能處理讀寫請求，因此必須依靠協(xié)調(diào)器（Coordinator）來為客戶端指派具體的 Broker、管理元數(shù)據(jù)，并重新實(shí)現(xiàn)那些原本由分區(qū) Leader 掌控的所有 Kafka 高級特性。

然而，這種對外部協(xié)調(diào)器的依賴也帶來了一些副作用。它引入了 Broker 自身之外的外部依賴，從而使數(shù)據(jù)寫入鏈路變得更加復(fù)雜。同時，這也推高了維護(hù) Kafka API 兼容性的成本，因?yàn)橹T如事務(wù)或冪等生產(chǎn)者等 Kafka 核心特性，都必須在協(xié)調(diào)器的深度參與下進(jìn)行徹底的重新實(shí)現(xiàn)。

AutoMQ 堅(jiān)持采用基于 Leader 的架構(gòu)，因此無需引入額外的“協(xié)調(diào)器”組件，其消息生產(chǎn)與消費(fèi)機(jī)制依然完美沿襲了 Kafka 的原生邏輯?？蛻舳藭?Bootstrap Broker 發(fā)起元數(shù)據(jù)請求，以獲知 Broker 列表、所在的可用區(qū)（AZ）以及各 Topic 分區(qū)的 Leader 信息。在生產(chǎn)數(shù)據(jù)時，客戶端會始終嘗試與指定 Topic 分區(qū)的 Leader 進(jìn)行交互；而在消費(fèi)端，客戶端既可以連接 Leader，也可以連接任意副本節(jié)點(diǎn)。

由于 AutoMQ 完整保留了 Leader 這一核心概念，因此系統(tǒng)架構(gòu)中無需任何額外的組件介入。

寫入靈活性

無 Leader 架構(gòu)賦予了寫入端極大的靈活性。

其顯著優(yōu)勢之一在于大幅削減了跨可用區(qū)（Cross-AZ）傳輸?shù)某杀?。系統(tǒng)能夠無縫地將流量從生產(chǎn)者路由至與其位于同一可用區(qū)的 Broker，從而避免了跨區(qū)流量費(fèi)用的產(chǎn)生。

AutoMQ 基于 Leader 的架構(gòu)憑借共享對象存儲的能力，同樣能夠輕松規(guī)避寫入側(cè)的跨可用區(qū)流量。這主要涵蓋兩種場景：

• 如果 Leader 與生產(chǎn)者處于同一可用區(qū)：太棒了，這是最理想的情況，生產(chǎn)者只需照常向該 Broker 發(fā)送消息即可。

• 如果 Leader 位于不同的可用區(qū)：當(dāng)生產(chǎn)者請求目標(biāo) Broker 信息以發(fā)送消息時，服務(wù)發(fā)現(xiàn)機(jī)制不會返回位于異地的 Leader 地址，而是會返回一個與生產(chǎn)者處于同一可用區(qū)的 Broker 地址。

該同區(qū) Broker 會先將接收到的消息寫入對象存儲的臨時文件中。隨后，Leader 會“認(rèn)領(lǐng)”這些臨時文件，并將數(shù)據(jù)正式寫入實(shí)際的分區(qū)位置。之所以采取這種機(jī)制，是因?yàn)樵诨?Leader 的架構(gòu)中，所有針對分區(qū)的最終寫入操作，必須由 Leader 親自經(jīng)手。

憑借這一設(shè)計(jì)，AutoMQ 在徹底消除跨可用區(qū)流量費(fèi)用的同時，并未犧牲 Kafka 的兼容性（因?yàn)?Leader 依然把控著分區(qū)數(shù)據(jù)的寫入權(quán)）。

讀取側(cè)的數(shù)據(jù)局部性

在 AutoMQ 這類基于 Leader 的系統(tǒng)中，分區(qū) Leader 擁有得天獨(dú)厚的優(yōu)勢：極高的數(shù)據(jù)局部性（Data Locality）。

由于 Leader 統(tǒng)管其名下分區(qū)的所有寫入操作，那些最新生成且被頻繁訪問的“熱數(shù)據(jù)（Hot Data）”可以被直接駐留在其本地內(nèi)存緩存中。

談及緩存，它堪稱 Diskless Kafka 架構(gòu)中的“生命線”。畢竟，直接從對象存儲讀取數(shù)據(jù)的性能表現(xiàn)，終究無法與本地磁盤相提并論。

除去性能層面的考量，過于頻繁的讀取請求還會導(dǎo)致成本激增，畢竟云服務(wù)商通常是依據(jù)對象存儲的 GET 請求次數(shù)來進(jìn)行計(jì)費(fèi)的。而在這一語境下，緩存機(jī)制不僅是提升性能的關(guān)鍵，更是兼顧成本效益（降本增效）的利器。

這不僅有助于提升讀取性能，還能最大化數(shù)據(jù)在上傳至對象存儲前的批處理效率。

正是基于這一架構(gòu)優(yōu)勢，AutoMQ 順理成章地設(shè)計(jì)出了雙層緩存機(jī)制：利用專用的日志緩存（Log Cache）來應(yīng)對寫入與熱點(diǎn)讀取，同時配備塊緩存（Block Cache）來服務(wù)于歷史數(shù)據(jù)。

反之，無 Leader 架構(gòu)則可能受制于數(shù)據(jù)局部性（Data Locality）較低的困境。

當(dāng)任意 Broker 隨時都能向同一分區(qū)寫入數(shù)據(jù)時，該分區(qū)的數(shù)據(jù)就會被打散，以碎片化的形式分布在 S3 的大量小對象中，而這些對象又是由不同的 Broker 各自生成的。

盡管這些對象最終會被合并，但在初始階段，Broker 仍不得不發(fā)起大量的 GET 請求，去拉取那些零散分布的對象以響應(yīng)消費(fèi)者。

緩存固然能緩解這一壓力。但核心難題在于：在無 Leader 架構(gòu)下，既然所有 Broker 都能承接讀取請求，該如何制定高效的數(shù)據(jù)緩存策略？

據(jù)我了解，為了解決這一問題，廠商們試圖將分區(qū)“綁定”給特定的 Broker。例如，WarpStream 利用一致性哈希算法將分區(qū)分配給特定的 Broker，由該節(jié)點(diǎn)全權(quán)負(fù)責(zé)指定分區(qū)的緩存與數(shù)據(jù)服務(wù)。

這種做法實(shí)際上是變相回歸了“基于 Leader”的架構(gòu)理念，但同時也為此引入了額外的復(fù)雜性。由于缺乏本地數(shù)據(jù)支持，為了填補(bǔ)由此產(chǎn)生的性能與成本缺口，工程團(tuán)隊(duì)不得不設(shè)計(jì)各種變通方案，以規(guī)避對象存儲的高延遲與昂貴的 API 調(diào)用成本（如 S3 GET 請求）。

例如，WarpStream blog 中曾詳細(xì)闡述了他們?nèi)绾卫?mmap 技術(shù)來最小化 S3 API 的開銷。而這，恰恰是為了緩解因無法實(shí)現(xiàn)真正的數(shù)據(jù)局部性而不得不付出的設(shè)計(jì)代價。

元數(shù)據(jù)管理

基于 Leader 與無 Leader 架構(gòu)之間的分歧，不僅停留在表面，更深入到了元數(shù)據(jù)管理的底層邏輯。在 AutoMQ 的基于 Leader 模型中，元數(shù)據(jù)管理顯得大道至簡，因?yàn)樗苯訌?fù)用了 Kafka 成熟的分區(qū)邏輯。

當(dāng) AutoMQ 寫入數(shù)據(jù)時，它會像原生 Kafka 那樣，直接將數(shù)據(jù)寫入一個已經(jīng)開啟的分區(qū)。這種設(shè)計(jì)使得元數(shù)據(jù)的存儲與組織變得異常直觀清晰。其元數(shù)據(jù)占用的空間相對較小，主要僅需追蹤兩類信息：分區(qū)與 Leader Broker 的映射關(guān)系，以及數(shù)據(jù)對象在 S3 中的存儲位置。

這一元數(shù)據(jù)管理重任，由 Kafka 原生的 KRaft 協(xié)議高效承接，該協(xié)議已直接集成于 Broker 核心之中。元數(shù)據(jù)的體量與消息批次的數(shù)量并不掛鉤，從而有效杜絕了數(shù)據(jù)膨脹的風(fēng)險。

反觀無 Leader 系統(tǒng)，則面臨著頗為棘手的挑戰(zhàn)。由于其在架構(gòu)層面剝離了消息分區(qū)的概念，團(tuán)隊(duì)不得不投入巨大的工程精力，編寫海量代碼，只為從零開始復(fù)刻 Kafka 的核心功能。

由于缺乏對分區(qū)日志擁有絕對控制權(quán)的“單一權(quán)威節(jié)點(diǎn)”，它們被迫對每一批次（Batch）的消息都保存詳盡的元數(shù)據(jù)，包括其偏移量（Offset）、時間戳以及所包含的分區(qū)數(shù)量。

這種復(fù)雜性體現(xiàn)在兩個維度。

首先，海量的元數(shù)據(jù)通常需要引入一個獨(dú)立的事務(wù)型數(shù)據(jù)庫來進(jìn)行管理。這不僅大幅增加了運(yùn)維的負(fù)擔(dān)，還為系統(tǒng)埋下了另一個潛在的單點(diǎn)故障隱患。

其次，它極大地復(fù)雜化了數(shù)據(jù)訪問鏈路。存儲在 S3 中的數(shù)據(jù)本身不再具備“自包含性”；消費(fèi)者若要讀取數(shù)據(jù)，必須將對象存儲中的原始數(shù)據(jù)與數(shù)據(jù)庫中對應(yīng)的元數(shù)據(jù)進(jìn)行動態(tài)拼接。

相比 AutoMQ 或傳統(tǒng) Kafka，這種合并過程要繁瑣得多。究其根本，這是因?yàn)闊o Leader 架構(gòu)拋棄了作為 Kafka 協(xié)議基石的那套簡單而高效的分區(qū)邏輯，從而不得不去承受的直接后果。

結(jié) 語

在本文中，我們首先審視了云原生時代 Kafka 所面臨的種種挑戰(zhàn)，剖析了 Diskless Kafka 架構(gòu)興起的背后動因及其核心內(nèi)涵。隨后，我們將目光投向了 AutoMQ 一一它是目前市場上唯一一款提供開源 Diskless Kafka 選項(xiàng)的解決方案。

最后，我們從額外組件需求、寫入靈活性、讀取側(cè)的數(shù)據(jù)局部性以及元數(shù)據(jù)管理這四個維度出發(fā)，深度對比了 Diskless Kafka 系統(tǒng)中的兩條主流技術(shù)路線：基于 Leader（Leader-based）與無 Leader（Leaderless）架構(gòu)的異同。