测试背景
当前小红书消息引擎团队与 AutoMQ 团队正在深度合作，共同推动社区建设，探索云原生消息引擎的前沿技术。本文基于 OpenMessaging 框架，对 AutoMQ 进行了全面测评。欢迎大家参与社区并分享测评体验。
01
测试结论
本文主要测评云原生消息引擎 AutoMQ 和 Apache Kafka（3.4 版本）的性能对比。
测试结论：
实时读写：相同集群规模，AutoMQ 的极限读写吞吐是 Apache Kafka 的3倍，E2E 延迟是 Apache Kafka 的 1/13
追赶读：相同集群规模，AutoMQ 的追赶读峰值是 Apache Kafka 的 2 倍，同时追赶读期间 AutoMQ 的写吞吐和延迟不受任何影响
分区迁移：AutoMQ 的分区迁移平均耗时为秒级别，而Apache Kafka分区迁移平均耗时为分钟甚至小时级
02
测试配置
基准测试在 Linux Foundation's OpenMessaging Benchmark 的基础上进行增强，模拟真实用户场景提供了动态工作负载。
2.1 配置参数
AutoMQ 默认数据强刷盘再响应，使用配置如下：
acks=all
flush.message=1AutoMQ 通过 EBS 底层的多副本机制来保障数据高可靠，在 Kafka 侧无需多副本配置。Apache Kafka 选择 3.4.0 版本，并参考 Confluent 的建议不设置 flush.message = 1，使用三副本内存异步刷盘来保障数据的可靠性（机房掉电故障会造成数据丢失），配置如下：
acks=all
replicationFactor=3
min.insync.replicas=22.2 机器规格
16c、最大网络带宽 800MB/S、配置一块 150MB/S 带宽的云盘
03
详细对比
3.1 实时读写性能对比
本测试测量 AutoMQ 和 Apache Kafka 在相同集群规模下，不同流量规模的的性能和吞吐上限。测试场景如下：
各自部署6台数据节点，创建 1 个 100 分区的 Topic
分别启动 100 MiB/s、200 MiB/s 的 1:1 读写流量(message size=4kb，batch size = 200kb)；此外额外测试二者的极限吞吐。
负载文件：tail-read-100mb.yaml、tail-read-200mb.yaml、tail-read-900mb.yaml
极限吞吐发送延迟：
极限吞吐：
发送耗时和 E2E 耗时的详细数据：
分析：
相同集群规模下， AutoMQ 的极限吞吐（870MB/S）是 Apache Kafka (280MB/S) 的 3 倍
相同集群规模和流量（200 MiB/s）下，AutoMQ 的发送延迟 P999 是 Apache Kafka 的 1 / 50, E2E 延迟是 Apache Kafka 的 1/13
相同集群规模和流量（200 MiB/s）下，AutoMQ 带宽占用是 Apache Kafka 的 1 / 3
3.2 追赶读性能对比
追赶读是消息和流系统常见的场景：
对于消息来说，消息通常用作业务间的解耦和削峰填谷。削峰填谷要求消息队列能将上游发送的数据堆积住，让下游慢慢的消费，这时候下游追赶读的数据都是不在内存中的冷数据。
对于流来说，周期性的批处理任务需要从几个小时甚至一天前的数据开始扫描计算。
额外还有故障场景：消费者宕机故障若干小时后恢复重新上线；消费者逻辑问题，修复后，回溯消费历史数据。
追赶读主要关注两点：
追赶读的速度：追赶读速度越快，消费者就能更快从故障中恢复，批处理任务就能更快产出分析结果。
读写的隔离性：追赶读需要尽量不影响生产的速率和延时。
测试
本测试测量 AutoMQ 和 Apache Kafka 在相同集群规模下的追赶读性能，测试场景如下：
各自部署6台数据节点，创建 1 个 100 分区的 Topic
以 300 MiB/s 的吞吐持续发送。
在发送 1TiB 数据后，拉起消费者，从最早的位点开始消费。
负载文件：catch-up-read.yaml
测试结果：
分析
相同集群规模下，AutoMQ 的追赶读峰值是 ApacheKafka 的 2 倍。
追赶读期间，AutoMQ 的发送流量没有受到任何影响， AutoMQ 的平均发送延迟上升了约 0.4 ms；而 Apache Kafka 的发送流量下降了 10%，平均发送延迟也飙升到了 900ms。这是由于，Apache Kafka 在追赶读时会读取硬盘，且没有做 IO 隔离，这占用了云盘的读写带宽，导致写硬盘带宽减少，发送流量下降；同时读硬盘中的冷数据会污染 page cache，同样会导致写入延迟升高。作为对比，AutoMQ 读写分离，在追赶读时不会读硬盘，而是读对象存储，不会占用硬盘读写带宽，也就不会影响发送流量和延迟。
3.3 分区迁移能力对比
本测试测量 AutoMQ 和 Apache Kafka 在带日常发送消费流量场景下，迁移一个具备 30 GiB 数据的分区到一个不存在该分区副本的节点的迁移耗时和影响。具体的测试场景为：
- 2 台 broker，在其上创建：
1 个单分区单副本的 Topic A，并以 40 MiB/s 吞吐持续读写。
1 个 4 分区单副本的 Topic B，并以 10 MiB/s 吞吐持续读写，作为背景流量。
- 10 分钟后，将 Topic A 的唯一一个分区迁移到另一个节点，迁移吞吐限制 100 MiB/s。负载文件：partition-reassign.yaml
分析
AutoMQ 分区迁移只需要将 EBS 中缓冲的数据上传到 S3 即可在新的节点安全打开，500 MiB 的数据通常在 2～5 秒内即可完成上传。AutoMQ 分区的迁移耗时和分区的数据量无关，分区迁移时间平均下来在 2 秒左右。AutoMQ 分区在迁移过程中向客户端返回 NOT_LEADER_OR_FOLLOWER 错误码，在迁移完成后客户端更新到新的 Topic 路由表，客户端内部重试发送到新的节点，因此该分区的此刻的发送延迟会上涨，迁移完成后恢复到日常水位。
Apache Kafka 分区迁移需要将分区的副本拷贝到新的节点，拷贝历史数据的同时还要追赶新写入的数据，迁移的耗时 = 分区数据量 / （迁移吞吐限制 - 分区写入吞吐），在实际生产环境中，分区迁移往往是小时级的，本测试中的 30 GiB 的分区迁移耗时就到了 15 分钟。除了迁移耗时长以外，Apache Kafka 迁移需要从硬盘读取冷数据，即使在设置了 throttle 的情况下，仍旧会因为抢占 page cache 导致发送延迟的抖动，影响服务质量。
END
关于我们
我们是来自 Apache RocketMQ 和 Linux LVS 项目的核心团队，曾经见证并应对过消息队列基础设施在大型互联网公司和云计算公司的挑战。现在我们基于对象存储优先、存算分离、多云原生等技术理念，重新设计并实现了 Apache Kafka 和 Apache RocketMQ，带来高达 10 倍的成本优势和百倍的弹性效率提升。
🌟 GitHub 地址：https://github.com/AutoMQ/automq
💻 官网：https://www.automq.com
)
