当 Kafka 架构显露“疲态”：共享存储领域正迎来创新变革

还展示了下一代开源项目 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 当作 “恰好共事的陌生人”。

三重（甚至更严重的）打击

接下来，让我们看看成本问题有多棘手。