AutoMQ: 一款真正的云原生 Kafka 解决方案 [开源项目]

介绍

AutoMQ 是基于云原生重新设计的新一代 Kafka 发行版。在保持和 Apache Kafka 100%兼容前提下，AutoMQ 可以为用户提供高达 10 倍的成本优势以及百倍的弹性优势，同时支持秒级分区迁移和流量自动重平衡，解决运维痛点。

AutoMQ 开源项目点我 Star

为什么您需要 AutoMQ ？

在生产场景大规模应用 Apache Kafka 集群时，企业必然会被如下问题所困扰：

成本高、膨胀快：大数据场景往往伴随高吞吐、保存大量数据，预留磁盘，不灵活，成本高。
分区迁移慢：扩缩容需要迁移分区并搬迁历史数据，动辄数小时，期间数据冷读也会影响服务。
缺乏流量重平衡：各节点分区和负载不同，缺乏自均衡机制，极易造成局部节点闲置或热点故障。

上述痛点归咎于 Apache Kafka 面向 IDC 、存算一体的设计思路而无法根本解决。如今，云计算已经用确定性服务重新定义了最早的硬件和软件。此时，有必要基于云重新设计 Kafka ，充分发挥底层云产品的服务化和无限资源池能力，彻底解决上述成本过高、无法弹性伸缩、运维效率低下的痛点。

架构理念和创新

从依赖硬件，转变为依赖服务
从预留资源，转变为按量付费
将存储分离至服务，而不是软件
共享存储优于无共享架构
依赖云厂商的“最大公约数”
面向云计费项进行架构设计

核心优势

10 倍成本优化，科学降本

AutoMQ 全新云原生架构充分利用对象存储、Spot 实例等云服务的数据高可用、弹性供给能力，相比 Apache Kafka 为客户带来 10 倍的成本优势。

以对象存储作为核心主存储，存储单价极大降低。
单副本高可用架构，节省 2/3 的流量复制成本。
充分利用 Spot 实例，结合弹性伸缩策略，降低计算成本。

秒级分区迁移和流量自平衡，Serverless 触手可及

AutoMQ 将存储状态完全分离至对象存储服务，业务逻辑层完全无状态。AutoMQ 集群可以在秒级时间内完成分区迁移和流量重平衡，彻底解决 Apache Kafka 扩缩容重平衡慢、迁移分区困难的痛点。配合云厂商弹性伸缩组策略，轻松实现集群自适应弹性伸缩。

100% 兼容 Apache Kafka

区别于其他厂商重新实现 kafka 协议的做法，AutoMQ 选择存储层极小切面替换的方式，只修改底层 LogSegment 实现，上层仍然复用 Apache Kafka 各版本主要代码。AutoMQ 可以轻而易举地实现和 Apache Kafka 100% 兼容，并可以快速兼容新版本。通过了 130+ 功能用例验证。

功能范围覆盖 1000+ KIP 。
兼容 0.9.0 ~ 3.4 版本。

wan0573

339 天前

@superhxnju 随着 Apache Kafka 3.6.0 的发布，KIP-405 多级存储存储方案终于问世，虽然该特性仍处于早期访问阶段，但确实仍然有不少开发者询问 AutoMQ 的架构相较于 KIP-405 核心优势在哪里。

如果我们在云上部署 Apache Kafka 或者 AutoMQ for Kafka （以下简称 AutoMQ Kafka ），确实两个架构有一定的相似性，都是基于 EBS 和对象存储（ S3 ）的部署形态，虽然在存储介质的选型上是一致的，但实际上如何用这两类存储的思想是不同的。

首先来讲 EBS：
- Apache Kafka 的架构将 EBS 视作普通的块设备存储介质，跟本地机房的一块物理硬盘没有本质的区别，所以 Apache Kafka 会基于 EBS 做数据复制，一般要求 3 副本。
- AutoMQ Kafka 将 EBS 视作高可靠、高可用的云存储服务，充分利用 EBS 自带 3 副本的可靠性（ 5 个 9 ～ 9 个 9 的可靠性）以及其在可用区内和可用区之间的故障转移能力，这使得 AutoMQ Kafka 可以避免在 EBS 之上做额外的复制，从而节省大量的存储、网络和计算资源。

再来看对象存储（ S3 ）：
- Apache Kafka 将 S3 用于第二级存储，第一级存储构建在 EBS 之上，从设计上来看，每个 Kafka Topic 的分区，至少最后一个活跃的 Segment 需要留在第一级存储之上。这也导致多级存储方案中的第一级 EBS 存储将使用多少存储空间是不固定的，往往跟分区数量有关系。
- AutoMQ Kafka 将 S3 作为主存，EBS 定位为高速写入缓冲区，更多的是一个低延迟的持久化缓存。因此 AutoMQ Kafka 的每个 Broker 仅需要 2GB 的 EBS 卷，其中仅 500MB 不在 S3 上的 Delta 数据（可配置）。

EBS 作为缓冲区，所以存储空间具备确定性，使得 AutoMQ Kafka 架构在 EBS 存储上开销极低，一块 2GB 的 EBS 卷每月花费仅 1 元，同时缓冲区里面仅最多有不超过 500MB 的数据是在 S3 上不存在的，可以做到秒级完成 S3 上传，进而能支持秒级的分区转移。

相反，多级存储架构中的一级存储空间不固定，需要对 EBS 进行容量评估，这往往是一件很困难的事情，所以我们仍然需要为每个 Broker 节点预置大容量的 EBS 卷。另一方面，每个分区遗留在 EBS 上的数据也不固定，所以分区移动时间也不确定，也没办法快速伸缩。以 Confluent 给出的案例来看，在一个大流量集群，扩容操作在非多级存储架构需要耗时 43 小时，在多级存储架构需要耗时 1.4 小时。可以看出，多级存储方案虽然大大缓解了 Kafka 架构上固有的问题，但无法像 AutoMQ Kafka 架构一样做到无状态。

总结一下，AutoMQ Kafka 的云原生架构相较于多级存储方案，是一个量变引起质变的过程，通过架构优化，使得 AutoMQ Kafka 做到「无状态」，任意伸缩，秒级分区转移。相反，多级存储架构是一个优化方案，仍然是有状态。

wan0573

336 天前

@9of6 感谢回复哈，针对你的问题，我这边谈下我的看法。公有云针对 EBS 一般都针对场景提供多种云盘的 SKU 。如果对持久性有更高的要求，像在 aws 上其实可以使用 io2(有 3 个 9 的持久性，并且支持多重挂载可以做更快的 failover)。对于 AutoMQ 来说，使用更好规格的云盘其实并不会导致大量的成本上升(这算是 AutoMQ 本身设计的一个亮点)，因为 AutoMQ 本质上把云盘作为一个具备持久性性的写入 cache ，加速写的。一般这个大小只要配置 3GB 左右的云盘即可打满单机百 MB/s 的带宽。此外，云的基础设施底座还在不断发展的，像 GCP 上就有支持跨可用区的云盘，可以预见，国内外主流云厂商提供更加丰富的云盘 SKU 和跨可用区云盘能力的跟进是指日可待的》

wan0573

336 天前

@metaluo 对于 AutoMQ 来说，在云上肯定是可以发挥最大的弹性、成本优势(主要是云上的云盘、对象存储和按需使用的计算资源)。如果你是纯粹不使用云的场景，私有部署的话，也就是意味着没有云上的这些基础设施底座，对于弹性、成本这方面的效果就会差一些，但是仍然是可以使用 AutoMQ 替换 Kafka 来提升运维效率和降低成本的。在纯私有环境使用 AutoMQ 一般要求有 HDFS 或者 minio 这样的存储底座即可，AutoMQ 自身的自动流量重平衡、极速分区移动、写低成本存储层的能力仍然是具备的。