Kafka 4.0 在 2026 年 1 月把 ZooKeeper 整包拔掉、KRaft 成為唯一的共識機制，官方版本頁面上寫得像是自架 Kafka 的 ops 負擔終於變輕了。實際跑過的人都知道，ZooKeeper 從來不是自架 Kafka 最貴的那一段——真正吃掉整份帳單的，是每個 partition 都得跨三個 AZ 存三份、每次寫入都要在 AZ 之間拉一次網路的複本費用，這條線 4.0 完全沒動。AutoMQ 是 2024 年開始把這個架構整個翻掉的專案，2026 年 8 月推進到 1.5.5，GitHub 上累積 10.4k 星，做的事情用一句話講就是：把 Kafka 的儲存層搬到 S3、broker 從有狀態變成無狀態，跨 AZ 複本這件事直接讓物件儲存自己解決。
AutoMQ 是 Apache Kafka 的 fork，不是又一個「Kafka 相容」的重寫。這個定位在跟 Redpanda、WarpStream 比較的時候很關鍵——AutoMQ 拿的是 Apache Kafka 的 JVM 執行緒模型、UnifiedLog、Controller 全部原封不動，只把 LocalLog 跟 LogSegment 那一層抽掉，換成走 S3 API 的 S3Stream。Kafka Streams、Kafka Connect、任何吃 Kafka 協議的 client library 完全不用改，這在生態相容度上比 Redpanda 那種 C++ 重寫或 WarpStream 那種 Go 重寫都乾淨。
三份複本這件事，KRaft 也解不掉
傳統 Kafka 部署在 AWS 上的成本結構長期以來都是同一個樣子。每個 partition 三份 replica、分佈在三個 AZ 上，每寫入 1 GB 資料就得跨 AZ 傳 2 GB，AWS 對跨 AZ 流量收 $0.01/GB 兩端合計 $0.02/GB。實務上跑過 100 MB/s 吞吐量的 Kafka 叢集就會知道，這筆帳單一個月動輒五位數美金，比 EC2 本身還貴。
問題根源在於 Kafka 從 2011 年設計那天起就假設儲存是 broker 本地磁碟——這個 shared-nothing 架構在資料中心自建時代是正解，但搬到雲上之後就顯得很怪。物件儲存本身就已經做了 11 個 9 的耐久度跟跨 AZ 複製，broker 自己再複製一次等於重工。Kafka 4.0 的 Tiered Storage 有想解這個問題，但作法是「熱資料還是三份本地、冷資料才丟去 S3」，複本費用只降了一半，broker 依舊有狀態、擴縮容依舊要搬資料。
AutoMQ 的取捨是走到底：所有資料一律走 S3、broker 完全不存持久化資料。這個決定表面上簡單，實作上要處理的細節不少——最主要的是 write-ahead log 該放哪、怎麼在 S3 高延遲的物理特性下維持 Kafka 承諾的低毫秒延遲。
S3Stream 的 WAL 分層設計
S3 的 PUT 延遲落在 20 到 100 毫秒之間，比 Kafka 那種 3 到 5 毫秒的 P99 承諾差了一個數量級。要在這種延遲條件下維持相容體驗，AutoMQ 走的是 WAL 加緩存的雙層策略。
寫入路徑上，Producer 送過來的資料先進 broker 本地的 WAL，這個 WAL 可以放在 EBS、本地 SSD、或雲廠商的 FSx 這類低延遲塊儲存上。WAL 命中之後 broker 立刻回 ack，滿足低延遲承諾。背景 flush 執行緒再把 WAL 累積到一定量（預設 128 MB）之後批次上傳到 S3，這樣既壓低了 S3 PUT 的次數（每 MB 只要 0.005 美金但按次計費會很痛），又利用了 S3 的高頻寬特性。
讀取路徑上，熱資料由 broker 記憶體的 BlockCache 供應，冷資料才回 S3 拉。這個設計對消費者長期追趕 lag 的場景反而更友善——傳統 Kafka 要保留很久的資料就得配大磁碟，AutoMQ 直接讓 S3 當儲存池，broker 磁碟只要撐得住熱資料就好。
實際數字上，AutoMQ 官方在 AWS Multi-AZ 環境下量到的 producer 延遲是 median 5 毫秒、P99 20 毫秒，比 Kafka 慢一點但落在多數應用可接受範圍。FSx WAL 場景下寫入 460 MB/s、讀取 1840 MB/s、端到端延遲 P99 28 毫秒，這個數字在物件儲存為後盾的架構裡已經算是很極限。
broker 秒級擴縮容怎麼變成真的
Kafka 4.0 之前擴一個 broker 進來，要做的事情是把某些 partition 從舊 broker 搬到新 broker。這個 rebalance 過程資料量動輒好幾百 GB，跑幾個小時是常態，期間叢集吞吐量還會被拖慢。這也是為什麼傳統 Kafka 自架團隊都習慣「過度採購」——寧可一開始開大一點，也不要在流量突增時被 rebalance 卡死。
AutoMQ 的 broker 無狀態化把這件事變成 metadata 操作。新 broker 上線後只要 controller 把 partition ownership 改寫一下（毫秒級操作），該 broker 立刻就能對外服務——資料本來就在 S3、不需要搬。Auto Balancer 這個內建元件會根據流量自動搬 partition，不用再裝 Cruise Control 這類外掛。
這個特性在應對突發流量的場景差距很大。傳統 Kafka 要開新 broker 得等 rebalance、通常反應不了尖峰；AutoMQ 可以在 60 秒內把叢集容量加倍。對於做電商促銷、直播平台、或任何流量本身就有明顯波峰波谷的業務，這是實實在在省錢的路線——尖峰過去就縮回去，不用整個月開著。
Redpanda 走 NVMe、AutoMQ 走 S3，該怎麼選
Redpanda 跟 AutoMQ 常被放在同一個對照組，但兩者的取捨方向其實是相反的。Redpanda 用 C++ 從頭寫、把資料塞在 broker 本地 NVMe 上，優化目標是把延遲壓到 sub-millisecond。AutoMQ 用 Java 保留 Kafka 完整生態、把資料丟到 S3，優化目標是把雲端成本砍掉。
延遲面 Redpanda 贏，寫入延遲 P99 通常在 1 到 3 毫秒之間、比 Kafka 還低。但這個優勢有前提——broker 得跑在有 NVMe SSD 的機器上，儲存容量跟計算綁死，擴容依舊要搬資料。對於高頻交易、電競配對這類真的很在意 tail latency 的場景值得。
成本面 AutoMQ 贏得比較徹底。官方對比數字說 10x cost effective 有行銷成分，但把跨 AZ 流量費用、三份複本佔用的 EBS、broker 過度採購全算進去，5 到 8 倍的節省在典型雲端部署是合理的。對於自架訊息骨幹但又不想每個月看到雲廠商帳單心臟痛的團隊，這條路線的吸引力很直接。
實務上的判斷是：如果延遲是硬需求（P99 必須 <5 ms）、且叢集規模不大到成本痛，選 Redpanda；如果延遲有 20 毫秒的容忍空間（大部分事件驅動、日誌管線、CDC 場景都符合）、且雲端成本或擴縮容彈性是關鍵痛點，選 AutoMQ。想留在 Apache Kafka 生態系但又想解掉這些問題，AutoMQ 是唯一保留 100% 相容性的選項。
自架 MinIO 撐 AutoMQ 的實際細節
AutoMQ 走 S3 API 這件事意味著只要有 S3 相容的物件儲存就能跑，MinIO 是最常見的自架選擇。官方文件明確支援 MinIO 部署，操作路徑不複雜——起一個 MinIO 叢集、建兩個 bucket（一個給資料一個給 ops metadata）、用 automq-kafka-admin.sh generate-s3-url 產生連線字串、餵給 AutoMQ broker 就能跑起來。
但這裡有個關鍵細節值得標出來：MinIO 本身沒有提供塊儲存耐久度，如果連 WAL 都寫在 MinIO 上，AutoMQ 的高耐久度承諾就會破功。官方建議是 WAL 走本地 SSD、資料才走 MinIO。這個組合在自架場景其實反而更合理——本地 SSD 成本低、寫入延遲穩定，MinIO 只承擔冷資料落地跟長期保存，配置上跟一般想像的「純物件儲存」不同。
叢集規模建議是 5 台以上的 broker、每台配 2 核 16 GB、兩個虛擬儲存卷（一個給系統一個給 WAL），加上獨立的 MinIO 叢集。這個配置在一般臺灣機房 VPS 上是可以撐起來的——重點在網路，broker 跟 MinIO 之間的頻寬直接決定吞吐量上限，最好都放在同一機房內走內網。
一個常被忽略的雷區是 MinIO 的耐久度模式。單 node MinIO 只等於本地磁碟，AutoMQ 要撐 production 至少要跑 MinIO 的 distributed mode（4 node 起跳、erasure coding 保護）。這個要求把最小自架配置拉高到「5 台 AutoMQ broker + 4 台 MinIO」的 9 節點規模，比裝一套原生 Kafka 還複雜。反過來說，這個規模上單機能省的複本成本已經比 Kafka 划算，只是入場門檻不小。
AutoMQ 該不該接手訊息骨幹這一層
AutoMQ 在 2026 年已經有 Grab、京東、騰訊雲、Geely 這些大流量客戶在跑，成熟度已經到「主流公司會信任的等級」。開源版本走 Apache 2.0，付費版本主要加值在跨區複製、審計日誌、託管介面這些企業功能，核心引擎完全開源、沒有 open core 陷阱。
但它不是萬用解。以下場景不建議跳過來：延遲敏感型應用（金融訂單、即時競價）、流量規模小到本來就不介意 Kafka 那點成本（每天 <10 GB）、團隊沒有 S3 相容儲存營運經驗、或者本來訊息量小到 RabbitMQ、NATS JetStream 這類更輕量方案就夠用。這些場景硬套 AutoMQ 反而是自找複雜度。
適合跳過來的訊號很清楚：叢集規模大到跨 AZ 流量費用已經是月報表上的紅字、業務流量本身有明顯波峰波谷讓過度採購成本痛、儲存需求增長速度快於計算需求（典型的日誌管線、CDC、事件溯源）、或者未來計劃跨機房或跨區部署但不想自己造輪子解複製問題。
在自架路線上，AutoMQ 這種「保留成熟協議、換掉底層儲存」的思路可能會是接下來幾年的主流。同樣的想法已經在資料庫層看到（Neon 之於 Postgres、SlateDB 之於 RocksDB），訊息佇列層 AutoMQ 是第一個把它做到 production 品質的案例。傳統 Kafka 的操作經驗完全可以複用、監控告警指標一致、遇到問題還能查 Kafka 的 25 年知識庫，這個切換成本比「換一套全新系統」低太多。
NCSE Network 在臺灣是方電訊機房提供採用 Intel Xeon Gold CPU 與 NVMe SSD 的 VPS 主機，多節點內網互通、可依需求規劃 MinIO 儲存池與 AutoMQ broker 分工的架構。前往 ncse.tw 了解機房規格與方案細節。
