文章导读

在云原生架构日益普及的今天，越来越多企业将 Apache Kafka 部署到 AWS 、GCP 等公有云平台。但很多架构师在实践中发现：
Kafka 云上运行成本远超预期，特别是 ** 跨可用区（AZ）之间的数据传输费用 ** ，常常成为账单里的“隐形杀手”。

据 Confluent 披露， ** 跨 AZ 网络流量成本甚至可能占总成本的 50% 以上 ** ，让本就复杂的 Kafka 运维更添压力。

那么，有没有一种方法， ** 在不牺牲高可用与性能的前提下，将跨 AZ 网络开销彻底归零？ **

今天这篇文章，将为你揭开 AutoMQ 的“零成本复制”技术原理。

💡 AutoMQ 是由 Apache RocketMQ 核心团队重新设计的一款新一代云原生 Kafka ，100% 兼容 Kafka
协议，专为云环境下的弹性与成本优化而生。通过存算分离、 对象存储 优先和云原生调度机制，AutoMQ 可帮助企业显著降低 Kafka
云部署成本，实现更灵活的扩缩容能力。目前已在 GitHub 开源，Star 数接近 6.8k，受到全球开发者关注。

作为 Kafka 在云上的创新解法，AutoMQ 引入 ** S3 WAL 、智能自平衡调度、机架感知 Broker 映射 **
等三大核心能力，让生产数据始终停留在本地可用区，从根源上规避 Kafka 云部署中的数据复制成本陷阱。

全文图文并茂，深入浅出，不仅剖析了 AutoMQ 云原生架构的核心设计理念，更展示了真实场景下的网络成本对比数据。如果你正在为 Kafka
的云上成本优化发愁，这是一篇不容错过的技术干货！

注意：内容原始内容为英文，如需追求最原汁原味和准确的阅读体验，请直接点击底部 [查看原文] 阅读原始英文素材。

** 简介 **

如果你对消息或流处理系统感兴趣，那你肯定听说过 Kafka。而且很可能，你也见过无数号称“比 Kafka 更强”的解决方案。

这说明了两件事：首先，Kafka 由于其强大的通用性，越来越多企业将其纳入基础设施中（说明市场在快速增长）；其次，许多用户在使用 Kafka
的过程中仍然面临不小的挑战，尤其是在如今这个云计算时代（意味着有许多痛点亟待解决）。

当你把 Apache Kafka 部署到云上时，它的 replica factor 会导致 Leader
节点将接收到的数据发送给位于不同可用区（Availability Zone，AZ）内的 Follower 节点。与计算和存储成本相比，跨 AZ
的数据传输成本一开始可能并不明显；但根据 Confluent 的观察，这部分传输成本居然可以占到总账单的 50% 以上（后文会详细介绍）。

在我之前发布的一篇关于 WarpStream [1] 的文章中，我们发现 WarpStream 通过“劫持”服务发现机制，让客户端始终连接到同一个可用区内的
Broker，从而规避了跨 AZ 的传输费用。而这背后的关键在于 WarpStream 对 Kafka 协议的重写。

本周，我们将深入探讨 AutoMQ —— 一个 100% 兼容 Kafka 的替代方案，看看它是如何帮助用户显著降低跨 AZ 数据传输成本的。AutoMQ
的设计理念是：在云环境下高效运行 Kafka，核心方式是保留 Kafka 协议栈（即复用 Kafka 代码），并重写底层存储架构，通过引入
WAL（预写日志）机制将数据高效卸载至对象存储。

不久前，我写过一篇关于 AutoMQ 的详细文章，你可以查看这篇文章[2]。

本文将按以下结构展开：首先，我们会回顾 Confluent 对 Apache Kafka 的观察；接着介绍 AutoMQ 的整体架构；最后，我们将揭示
AutoMQ 如何帮助用户降低数据传输成本。

为了更方便地说明原理，文中将使用 AWS 上的服务（如 S3 或 EBS）来类比 AutoMQ 的功能模块。

** 01 跨 AZ（Availability Zone）成本 **

Apache Kafka 最初是在 LinkedIn 开发的，用于应对该公司对日志处理的高强度需求。Kafka 的设计深度契合 LinkedIn
的运行环境，工程师们通过充分利用页面缓存（Page
Cache）和磁盘的顺序访问模式对其进行了优化。这种方式既能实现极高的吞吐量，又能保持系统架构的简洁，因为大多数与存储相关的任务由操作系统自动处理。

Kafka 依赖副本机制（Replication）来保证数据的持久性。当 Message 被写入 Leader 分区时，必须同步复制到 Follower
分区。Kafka 最初运行于 LinkedIn 自建的数据中心环境中，在那种场景下，基础设施团队在 Leader 向不同数据中心的 Follower 复制
Message 时，并不需要考虑网络传输成本。

然而，当用户将 Kafka 部署到云上时，情况发生了变化。为了保证高可用性，Leader 节点需要将数据复制到位于不同可用区（Availability
Zone，简称 AZ）中的 Follower 节点，以应对某个 AZ 宕机时的数据恢复需求。但在云上，跨 AZ 的数据传输是需要额外付费的。根据
Confluent 的观察，当用户自建和管理 Apache Kafka 时，仅由于副本同步带来的跨 AZ 数据传输成本，可能会占据基础设施总成本的 50%
以上，这一数字令人惊讶。

下面用一组数据来帮助理解这一现象：设想一个 Kafka 集群包含三个 Broker，分别部署在三个不同的可用区内。如果某个 AZ 中的 Broker
发生故障，集群仍可依赖另外两个 Follower 继续提供服务。一个负载均衡良好的集群会将 Partition 的 Leader 分布在三个 AZ
中，这意味着 Producer 大约有三分之二的时间会向其他 AZ 中的 Leader 写入数据。

一旦 Leader 接收到 Message，它会将数据复制到其他可用区（AZ）中的 Broker，以确保高数据可靠性。这一过程会产生是原始生产请求两倍的跨
AZ 流量。

简而言之，Apache Kafka 的多 AZ 部署架构将至少产生（2/3 + 2）倍的跨 AZ 单价流量成本（以 AWS 为例，跨 AZ 数据传输为
$0.01/GB，进出流量分别收费）。

下面的计算不包含 Consumer 侧产生的跨 AZ 成本。

假设使用三台 r6i.large（2 核心，16GB 内存）配置的 Broker，可提供约 30MiB/s 的写入吞吐量，那么 Apache Kafka
每月产生的跨 AZ 流量成本如下：

30 × 60 × 60 × 24 × 30 ÷ 1024 × (2/3 + 2) × 0.02 ≈ $4050

而虚拟机（VM）的成本仅为：

3 × 0.126 美元/小时（r6i.large 单价）× 24 × 30 = $272（仅为跨 AZ 成本的 6.7%）

接下来的部分将介绍 AutoMQ 如何帮助用户降低跨 AZ 成本在，此之前，我们先简要回顾一下 AutoMQ。

** 02 AutoMQ 概览 **

AutoMQ 的目标是在不牺牲性能的前提下，将所有 Message 写入 Object Storage （对象存储），从而提升 Kafka
的运行效率与灵活性。

为实现这一目标，AutoMQ 复用了 Apache Kafka 的计算与协议代码，并引入共享存储架构以取代 Kafka Broker
的本地磁盘。从宏观角度看，AutoMQ 的 Broker 首先将 Message 写入内存缓存（Memory Cache）。为了确保持久性，在将数据异步写入
Object Storage 之前，必须先写入 Write-Ahead Log（WAL）存储。

WAL 是一种仅追加的磁盘结构，常用于故障恢复与事务恢复。在数据库系统中，变更内容会优先写入该结构，再被真正写入数据库。

AutoMQ 使用堆外缓存内存层来处理所有 Message 的读写操作，提供实时性能体验。EBS 设备在 AutoMQ 中充当 WAL。当 Broker
接收 Message 时，它先将数据写入内存缓存，并在持久化至 WAL 后才返回确认响应。EBS 同时也用于 Broker 故障后的数据恢复。

所有 AutoMQ 的数据都会被存储在对象存储中，如 AWS S3 或 Google GCS。Broker
会将日志缓存中的数据异步写入对象存储。在元数据管理方面，AutoMQ 利用了 Kafka 的草稿模式（Draft Mode）。

AutoMQ 的 WAL 一大优势是其高度灵活性，用户可以根据自身业务场景选择不同的存储方案。例如，若未来 AWS
推出更高级的磁盘设备，用户即可无缝切换至新方案，以进一步提升 AutoMQ 的性能。

在下一节中，我们将探讨 AutoMQ 如何在使用 S3 作为 WAL 时减少跨 AZ（Availability Zone，区域内设计上与其他 AZ
灾难隔离的独立位置）成本近 100% 的解决方案。

** 03 AutoMQ 如何降低跨可用区成本 **

**
**

** 生产路径（Produce Path） **

当使用 EBS WAL 时，虽然无法完全消除跨可用区（cross-AZ）数据传输成本，但由于数据直接存储在 S3 而无需在 Broker
之间复制，AutoMQ 仍能大幅降低网络开销。不过，当生产者（Producer）向 Leader Partition 发送消息时，仍会产生跨可用区流量费用。

AutoMQ 提出了一种创新方案——采用 S3 作为 WAL，从而彻底消除跨可用区数据传输成本。与先写入 EBS 再同步至 S3 的传统方式不同，S3
WAL 允许 Broker 直接将数据写入 S3，并确保生产者仅将消息发送至同一可用区（AZ）内的 Broker。

在 Kafka 中，Producer 会先向 Bootstrap Servers 发送元数据请求，以获取包括 Partition Leader Broker
信息在内的集群元数据，随后才正式发送 Message。写入操作始终由 Leader Partition 处理——客户端生产数据时，只会与目标 Topic
Partition 的 Leader 进行通信。

在 Kafka 中，所有写入操作（Write）都必须通过 Leader 完成。

在 AutoMQ 中使用 S3 WAL 时，情况就不同了。假设这样一个场景：Producer 位于 AZ1，而分区 P2 的 Leader（B2）位于
AZ2，同时 AZ1 中还运行着 Broker B1。让我们来看看这种架构下 Message 的完整生产路径。

ꔷ 当 Producer 需要向 P2 写入数据时，首先会向 Bootstrap Brokers 集群发送元数据请求。关键的是，Producer
必须在请求中携带其所在的可用区信息（本例中为 AZ1）

在 Kafka 中，Producer 发起元数据请求后，可能会获取到与其不在同一可用区（AZ）的 Broker B2 信息，从而导致跨 AZ 通信成本，而
AutoMQ 的设计目标正是要规避这一问题。

ꔷ 在 AutoMQ 端，通过一致性哈希算法（Consistent Hash Algorithm）将 Broker 映射到不同 AZ。例如，假设
AutoMQ 将 AZ2 中的 B2 映射到 AZ1 中的 B1。由于 AutoMQ 知道生产者 Pr1 位于 AZ1（基于元数据请求），因此将返回 B1
的信息作为响应。如果生产者与 B2 位于同一 AZ，则返回 B2 的信息。核心思想是确保生产者始终与同一 AZ 中的 Broker 通信，从而有效避免跨
AZ 通信。

ꔷ 当 Producer 收到 B1 的信息后（请注意，该 Broker 并非目标分区的负责节点），就会开始向 B1 发送消息。

ꔷ B1 会先将消息缓存在内存中，当数据量达到 8MB 或经过 250ms 后，就会将缓冲数据作为临时文件写入对象存储。

ꔷ 最精妙的部分来了：当消息成功写入 S3 后，B1 会向实际的分区 Leader（B2）发起 RPC 调用，通知临时数据的位置信息（这会导致不同 AZ
间的 Broker 产生少量跨区流量）。

ꔷ 接着 B2 会读取这些临时数据，并将其追加到目标分区 P2 中。待 B2 完成数据写入后，会先响应 B1，最终由 B1 向 Producer
发送确认回执。

以下是一个图示，来帮助理解整个过程：

这种方案虽然能完全消除跨可用区（AZ）的数据传输成本，但客户需要部署比使用 EBS WAL
时更多的虚拟机实例（Broker）。原因与云环境中虚拟机和网络吞吐量的限制有关。相较于 EBS WAL，该方案需要从 S3
读取额外数据，这会占用虚拟机的网络带宽。换言之，S3 WAL 需要通过增加 VM 数量来应对提升的网络吞吐需求，从而确保其读写性能与 EBS WAL
保持同等水平。

** 消费路径（ ** Consume Path ** ） **

在消费路径（Consume Path）方面，AutoMQ 的处理流程与 Kafka 几乎完全一致。得益于 100%的 Kafka 兼容性，AutoMQ
消费者（ Consumer ）能够直接利用 Kafka 的 Rack-awareness 特性，确保始终从同一 AZ 内的 Broker 拉取数据。

关于 AutoMQ 如何帮助消费者避免跨 AZ 成本，还有一个关键因素是其内部自平衡机制（Self-balancing
Mechanism）。该机制包含内置的 Rack-aware 分区调度功能，可以自动将分区均衡分配到多个 AZ 的 Broker 上。

虽然 Apache Kafka 本身支持 Rack-aware 机制，但仅靠这一特性并不能完全消除跨 AZ 流量。要彻底避免跨 AZ 流量成本，Kafka
需要确保分区在扩缩容、迁移等所有操作过程中都保持 AZ 间的均衡分布。AutoMQ
通过其自平衡机制自动为用户管理这些任务，这不仅确保了流量的平衡，系统在故障时可以自我恢复，而且极大地降低了跨 AZ 流量成本。

后续我将专门介绍 AutoMQ 的自平衡机制实现原理。

** ** Observation ** **

用户可以根据不同场景选择最适合的 WAL 解决方案。在延迟敏感型场景中（如反欺诈、金融交易或实时数据分析），EBS WAL
是更优选择；而对于延迟要求不高的用例（如日志收集或可观测数据摄取），S3 WAL 能显著降低成本。

从上述分析可见，WAL 实现在 AutoMQ 中起着关键作用。其 WAL 采用可插拔设计，这意味着当出现更先进的云存储方案（如近期推出的 S3
Express One Zone）时，用户可轻松将其集成到 WAL 中。这种设计使 AutoMQ 能充分发挥新兴云存储方案的优势，适配多样化用户场景。通过
WAL 抽象层，AutoMQ 可快速获得不同云存储介质的特性收益，这正是 AutoMQ 所倡导的 “ One for All ” 理念。

** 结语 **

在本文中，我们了解到，当用户在云上运行 Apache Kafka
时，跨可用区（AZ）成本可能占据云账单的很大一部分。这些成本主要来自两个因素：Producer 向不同 AZ 中的 Leader 发送流量，以及需要在
Brokers 之间复制数据。

接下来，我们探讨了 AutoMQ 是如何应对这一挑战的：它允许 Producer 将消息发送至同一可用区内的 Broker，数据以批量形式写入
S3，随后由对应的分区 Leader 拉取并追加至目标分区。通过这种方式，AutoMQ 几乎完全消除了跨 AZ 成本（仅在 Broker 之间发起 RPC
请求时仍会产生少量跨区流量）。

感谢您的阅读，我们下篇文章再见！

** 参考资料 **

[1] I spent 8 hours researching WarpStream

[2] How do we run Kafka 100% on the object storage?

[3] With the help of Kaiming Wan, Director of Solutions Architect & Lead
Evangelist @ AutoMQ

[4] AutoMQ official documentation

[5] AutoMQ blog