還展示了下一代開源項目 AutoMQ 如何借助云原生設計，解決 Kafka 在成本、擴展性與運維方面的痛點，為實時數據流架構提供全新視角。

1Kafka：數據運營與數據分析之間的橋梁

我已經使用 Apache Kafka 多年，并且非常喜歡這個工具。作為一名數據工程師，我主要將它用作連接數據運營端與數據分析端的橋梁。憑借優雅的設計和強大的功能，Kafka 長期以來一直是流處理領域的標桿。

Kafka 扮演著連接數據運營端與數據分析端的橋梁角色。

自問世以來，Kafka 就憑借獨特的分布式日志抽象，塑造了現代流處理架構。它不僅為實時數據流處理提供了無可比擬的能力，還圍繞自身構建了完整的生態系統。

Kafka 的成功源于其核心優勢：能夠大規模地實現高吞吐量與低延遲處理。這一特性使其成為各類規模企業的可靠選擇，并最終確立了其在流處理領域的行業標準地位。

但 Kafka 的發展之路并非一帆風順。它的成本可能急劇攀升，而在流量高峰時段進行分區重分配等運維難題，更是令人頭疼不已。

我至今還記得在沃爾瑪工作時的經歷：曾花費數小時排查一次恰逢流量高峰發生的分區重分配問題，那次經歷幾乎讓我心力交瘁。

盡管成本居高不下，Kafka 在流處理領域的主導地位依然穩固。在如今云優先的大環境下，一個多年前基于本地磁盤存儲設計的系統，至今仍是眾多企業的核心支撐，這著實令人意外。

深入研究后我發現，背后的原因并非 Kafka “完美無缺”，而是長期以來缺乏合適的替代方案。其最大的賣點 —— 速度、持久性與可靠性，至今仍具有重要價值。

但只要使用過 Kafka，你就會知道：它將所有數據都存儲在本地磁盤上。這一設計暗藏著一系列成本與挑戰，包括磁盤故障、擴展難題、突發流量應對，以及受限于本地或私有部署存儲容量等問題。

幾個月前，我偶然發現了一個名為 AutoMQ的開源項目。起初只是隨意研究，后來卻深入探索，徹底改變了我對流處理架構的認知。

因此，在本文中，我們希望分享兩方面內容：一是 Kafka 傳統存儲模型面臨的挑戰，二是以 AutoMQ為代表的現代解決方案如何通過云對象存儲（而非本地磁盤）另辟蹊徑解決這些問題。這一轉變在保留 Kafka 熟悉的 API 與生態系統的同時，讓 Kafka 具備更強的擴展性、更高的成本效益與更優的云適配性。

2不容忽視的問題：Kafka 為何停滯不前

坦白說，Kafka 十分出色，它徹底改變了我們對數據流的認知。但每當我配置昂貴的 EBS 卷、看著分區重分配進程緩慢推進數小時，或是凌晨 3 點因某個 Broker 磁盤空間耗盡而被驚醒時，我總會忍不住思考：一定有更好的解決方案。

這些問題的根源何在？答案是 Kafka 的 shared-nothing 架構。每個 Broker 都像一個 “隱士”：獨自擁有數據，將其小心翼翼地存儲在本地磁盤上，拒絕與其他 Broker 共享。這種設計在 2011 年合情合理，當時我們使用私有部署服務器，本地磁盤是唯一的存儲選擇。但在如今的云時代，這就好比在所有人都使用谷歌云盤（Google Drive）的情況下，仍堅持使用文件柜存儲數據。

這種架構實際帶來了以下成本負擔：

• 9 倍的數據冗余（沒錯，你沒看錯 ——Kafka 3 倍副本 × EBS 3 倍副本）。

• 分區重分配進程極其緩慢，如同看著油漆變干。

• 完全缺乏彈性—— 嘗試對 Kafka 進行自動擴展，你會發現整個周末都要耗費在這上面。

• 跨可用區（AZ）流量費用高到讓首席財務官（CFO）頭疼。

3Kafka 的運維成本：Shared-Nothing 架構的代價

我想通過一個故事，直觀展現 Kafka 的成本問題。

假設你運營著一個小型電商網站，每小時僅攝入 1GB 數據，包括用戶點擊、訂單信息、庫存更新等，數據量并不算大。在過去，你只需將這些數據存儲在一臺服務器上即可。但如今是 2025 年，為確保高可用性，你選擇部署 Kafka。

而 Shared-Nothing架構在此刻開始讓你付出高昂代價。

Shared-Nothing 的真正含義

在 Kafka 的體系中，“Shared-Nothing” 意味著每個 Broker 都像一個 “多疑的隱士”，彼此之間不共享任何資源 —— 無論是存儲、數據，還是其他任何東西。每個 Broker 都擁有獨立的本地磁盤，自行管理數據，本質上把其他 Broker 當作 “恰好共事的陌生人”。

三重（甚至更嚴重的）打擊

接下來，讓我們看看成本問題有多棘手。