AutoMQ vs. Apache Kafka 性能对比
对比结论
100x 效率提升
相比 Apache Kafka 300 倍的分区迁移效率： AutoMQ 分区迁移速度相比 Apache Kafka 提升约 300 倍。AutoMQ 将 Kafka 高风险的常规运维动作，变成了可自动化，基本无感的低风险运维操作。
4min 从零到 1GiB/s 的极致弹性： AutoMQ 集群自动应急弹性从 0 MiB/s 到 1 GiB/s 仅需 4 分钟。它使得系统可以快速扩容响应突发流量。
相比 Apache Kafka 200 倍的冷读效率： AutoMQ 读写分离，相比 Apache Kafka 发送耗时降低 200 倍，追赶吞吐提高 5 倍。AutoMQ 可以轻松的应对在线消息削峰填谷和离线批处理的场景。
10x 成本节约
相比 Apache Kafka 2 倍吞吐极限： 相同的硬件规格，AutoMQ 极限吞吐是 Apache Kafka 的 2 倍，发送耗时 P999 为 Apache Kafka 的 1 / 4。在实时流计算场景，使用 AutoMQ 可以用更低的成本，更快的得到计算结果。
相比 Apache Kafka 1/11 的账单费用： AutoMQ 充分利用 Auto Scaling 和对象存储，相比 Apache Kafka 实现 11 倍的降本。使用 AutoMQ 无需再为峰值准备容量，实现真正的计算和存储按量付费。
测试准备
基准测试在 Linux Foundation's OpenMessaging Benchmark 的基础上进行增强，模拟真实用户场景提供了动态工作负载。所有测试场景均可以在 Github 代码库中找到配置和负载。
配置参数
AutoMQ 默认数据强刷盘再响应，使用配置如下：
acks=all
flush.message=1
AutoMQ 通过 EBS 底层的多副本机制来保障数据高可靠，在 Kafka 侧无需多副本配置。
Apache Kafka 选择 3.6.0 版本，并参考 Confluent 的建议不设置 flush.message = 1，使用三副本内存异步刷盘来保障数据的可靠性（机房掉电故障会造成数据丢失），配置如下：
acks=all
replicationFactor=3
min.insync.replicas=2
机器规格
从成本效益来说，小规格机型 + EBS 比带 SSD 的大规格机器更优。
以小规格 r6in.large + EBS vs. 大规格 i3en.2xlarge + SSD 为例：
i3en.2xlarge，8 核，64 GB 内存，网络基准带宽 8.4 Gps，自带两块 2.5 TB 的 NVMe SSD，硬盘最大吞吐 600 MB/s；价格 $0.9040/h。
r6in.large * 5 + 5 TB EBS，10 核，80GB 内存，网络基准带宽 15.625 Gbps，EBS 基准带宽 625 MB/s；价格 （计算）0.1743 * 5 + （存储）0.08 * 5 * 1024 / 24 / 60 = $1.156/h。
初看两者的价格和性能相差无几。考虑到实际生产中希望数据保存更久的时间，使用 i3en.2xlarge 只能水平扩容计算节点来提升集群的存储空间，浪费了计算资源。如果使用 r6in.large + EBS，只需要调整 EBS 的容量即可。
因此从成本、性能综合考虑， AutoMQ 和 Apache Kafka 计算均选择 r6in.large 作为 Broker 弹性最小单元，存储选择 GP3 类型的 EBS 和 Standard S3。
r6in.large：2 核，16 GB 内存，网络基准带宽 3.125 Gbps，EBS 基准带宽 156.25 MB/s；价格 $0.1743/h。
GP3 EBS：免费额度 3000 IOPS，125 MB/s 带宽；价格 存储 $0.08 GB 每月，额外带宽 $0.040 MB/s 每月，额外 IOPS $0.005 每月。
AutoMQ 和 Apache Kafka 对 EBS 的定位不同：
AutoMQ 用 EBS 作为写入缓冲区，因此 EBS 只需配置 3 GB 存储空间，IOPS 和带宽使用免费额度即可。
Apache Kafka 数据都存储在 EBS 上，EBS 空间由具体测试场景的流量和保存时间决定。额外购买 EBS 带宽 31 MB/s，进一步提高 Apache Kafka 的单位成本吞吐。
100x 效率提升
秒级分区迁移
在生产环境中，一个 Kafka 集群通常会服务多个业务，业务的流量波动和分区分布可能造成集群容量不足或者机器热点，Kafka 运维人员需要通过集群扩容，并且将热点分区迁移到空闲的节点，来保障集群的服务可用性。
分区迁移的时间决定了应急和运维效率：
分区迁移的时间越短，集群从扩容到容量满足诉求的时间越短，服务受损的时间越短。
分区迁移越快，运维人员观测的时间更短，可以更快的得到运维反馈决策后续的动作。
300x 效率提升，AutoMQ 相比 Apache Kafka 30 GiB 分区迁移耗时从 12min 下降到 2.2s。
测试
本测试测量 AutoMQ 和 Apache Kafka 在带日常发送消费流量场景下，迁移一个具备 30 GiB 数据的分区到一个不存在该分区副本的节点的迁移耗时和影响。具体的测试场景为：
2 台 r6in.large 作为 broker，在其上创建：
1 个单分区单副本的 Topic A，并以 40 MiB/s 吞吐持续读写。
1 个 4 分区单副本的 Topic B，并以 10 MiB/s 吞吐持续读写，作为背景流量。
13 分钟后，将 Topic A 的唯一一个分区迁移到另一个节点，迁移吞吐限制 100 MiB/s。
Apache Kafka 每台 broker 额外分别挂载一块 320GB 156MiB/s gp3 EBS 用于存储数据。
驱动文件：apache-kafka-driver.yaml，automq-for-kafka-driver.yaml
负载文件：partition-reassignment.yaml
AutoMQ 安装配置文件：partition-reassignment.yaml
| 对比项 | AutoMQ | Apache Kafka |
|---|---|---|
| 迁移耗时 | 2.2s | 12min |
| 迁移影响 | 最大发送延时 2.2s | 12min 内持续发送耗时 1ms ～ 90ms 抖动 |
分析
AutoMQ 分区迁移只需要将 EBS 中缓冲的数据上传到 S3 即可在新的节点安全打开，500 MiB 的数据通常在 2 秒内即可完成上传。AutoMQ 分区的迁移耗时和分区的数据量无关，分区迁移时间平均下来在 1.5 秒左右。AutoMQ 分区在迁移过程中向客户端返回 NOT_LEADER_OR_FOLLOWER 错误码，在迁移完成后客户端更新到新的 Topic 路由表，客户端内部重试发送到新的节点，因此该分区的此刻的发送延迟会上涨，迁移完成后恢复到日常水位。
Apache Kafka 分区迁移需要将分区的副本拷贝到新的节点，拷贝历史数据的同时还要追赶新写入的数据，迁移的耗时 = 分区数据量 / （迁移吞吐限制 - 分区写入吞吐），在实际生产环境中，分区迁移往往是小时级的，本测试中的 30 GiB 的分区迁移耗时就到了 12 分钟。除了迁移耗时长以外，Apache Kafka 迁移需要从硬盘读取冷数据，即使在设置了 throttle 的情况下，仍旧会因为抢占 page cache 导致发送延迟的抖动，影响服务质量，体现在图中为绿色曲线抖动的部分。
0 -> 1 GiB/s 极致弹性
Kafka 运维人员通常会根据历史经验准备 Kafka 集群容量，然而总会有一些非预期中的热门事件和活动导致集群流量陡增。这时候就需要快速的将集群扩容并重平衡分区，来应对突发流量。
极致弹性，AutoMQ 集群自动应急弹性从 0 MiB/s 到 1 GiB/s 仅需 4 分钟。
测试
本测试的目的是测量 AutoMQ 的 Auto Scaling 应急弹性功能自动从 0 MiB/s 到 1 GiB/s 的弹性速度。具体的测试场景为：
集群初始只有 1 个 Broker，设置 Auto Scaling 应急弹性容量为 1 GiB/s，创建一个 1000 分区的 Topic。
启动 OpenMessaging 直接将发送流量设置为 1 GiB/s。
驱动文件：apache-kafka-driver.yaml，automq-for-kafka-driver.yaml
AutoMQ 安装配置文件：emergency-scaling.yaml
| 分析项 | 监控报警 | 批量扩容 | Auto Balancing | 总计 |
|---|---|---|---|---|
| 0 -> 1 GiB/s 弹性耗时 | 70s | 80s | 90s | 4min |
分析
AutoMQ 的集群容量通常通过 Auto Scaling 的目标跟踪策略将集群水位维持在 80%。在非预期流量陡增场景，目标跟踪策略无法满足及时满足容量诉求，Auto Scaling 提供应急策略，当集群水位超过 90% 时，直接将集群弹性到目标容量。
本测试中 Auto Scaling 应急策略 4 分钟就将集群容量弹性到目标容量：
70s：AWS CloudWatch 监控最高的监控精度为 1 分钟。监控采集到集群水位超过 90%，并产生报警。
80s：AWS 批量扩容节点到目标容量，Broker 完成节点注册。
90s：AutoMQ 的 Auto Balancing 检测到节点间流量不均衡，完成流量自动重平衡。
集群容量满足 1 GiB/s 诉求，发送耗时回归基准时间。
追赶读（Catch-up Read）
追赶读是消息和流系统常见的场景：
对于消息来说，消息通常用作业务间的解耦和削峰填谷。削峰填谷要求消息队列能将上游发送的数据堆积住，让下游慢慢的消费，这时候下游追赶读的数据都是不在内存中的冷数据。
对于流来说，周期性的批处理任务需要从几个小时甚至一天前的数据开始扫描计算。
额外还有故障场景：消费者宕机故障若干小时后恢复重新上线；消费者逻辑问题，修复后，回溯消费历史数据。
追赶读主要关注两点：
追赶读的速度：追赶读速度越快，消费者就能更快从故障中恢复，批处理任务就能更快产出分析结果。
读写的隔离性：追赶读需要尽量不影响生产的速率和延时。
200x 效率提升，AutoMQ 读写分离相比 Apache Kafka 在追尾读场景，发送耗时从 800ms 下降到 3ms，追赶时间从 215 min 缩短到 42 min。
测试
本测试测量 AutoMQ 和 Apache Kafka 在相同集群规模下的追赶读性能，测试场景如下：
集群部署 20 台 Broker，创建 1 个 1000 分区的 Topic。
以 800 MiB/s 的吞吐持续发送。
在发送 4 TiB 数据后，拉起消费者，从最早的位点开始消费。
Apache Kafka 每台 broker 额外分别挂载一块 1000GB 156MiB/s gp3 EBS 用于存储数据。
驱动文件：apache-kafka-driver.yaml，automq-for-kafka-driver.yaml
负载文件：catch-up-read.yaml
AutoMQ 安装配置文件：catch-up-read.yaml
| 对比项 | 追赶读过程中发送耗时 | 追赶读过程中对发送流量影响 | 追赶读峰值吞吐 |
|---|---|---|---|
| AutoMQ | 小于 3ms | 读写隔离，维持 800 MiB/s | 2500 ~ 2700 MiB/s |
| Apache Kafka | 大约 800ms | 相互影响，下跌到 150 MiB/s | 2600 ～ 3000 MiB/s （牺牲写入） |
分析
相同集群规模下，在追赶读时，AutoMQ 的发送流量没有受到任何影响，而 Apache Kafka 的发送流量下降了 80%。这是由于，Apache Kafka 在追赶读时会读取硬盘，且没有做 IO 隔离，这占用了 AWS EBS 的读写带宽，导致写硬盘带宽减少，发送流量下降；作为对比，AutoMQ 读写分离，在追赶读时不会读硬盘，而是读对象存储，不会占用硬盘读写带宽，也就不会影响发送流量。
相同集群规模下，在追赶读时，相较于仅发送，AutoMQ 的平均发送延迟上升了约 0.4 ms，而 Apache Kafka 则飙升了约 800 ms。Apache Kafka 发送延迟升高有两方面原因：其一是前文提到的，追赶读会占用 AWS EBS 读写带宽，这会导致写入流量下降、延迟升高；其二是追赶读时，读硬盘中的冷数据会污染 page cache，同样会导致写入延迟升高。
值得说明的是，在追赶读 4 TiB 数据时，AutoMQ 花费了 42 min，Apache Kafka 花费了 29 min。Apache Kafka 耗时更短的原因有两个：
追赶读时，Apache Kafka 的发送流量下降了 80%，使得它需要追赶的数据变少。
Apache Kafka 并没有 IO 隔离，牺牲了发送速率来提升读取速率。
如果假设 Apache Kafka 有 IO 隔离，即，在尽可能保证发送速率的情况下进行读取，计算如下：
假设追赶读时 Apache Kafka 发送速率为 700 MiB/s，考虑三副本写入占用 EBS 带宽为 700 MiB/s * 3 = 2100 MiB/s。
而集群中的 EBS 总带宽为 156.25 MiB/s * 20 = 3125 MiB/s。
可用于读取的带宽为 3125 MiB/s - 2100 MiB/s = 1025 MiB/s。
在一边发送一边读取的追赶读场景下，读取 4TiB 数据需耗时 4 TiB * 1024 GiB/TiB * 1024 MiB/GiB / （1025 MiB/s - 700 MiB/s） / 60 s/min = 215 min。
Apache Kafka 在尽可能不影响发送的情况下，需耗时 215 min 追赶读完 4 TiB 数据，是 AutoMQ 耗时的 5 倍。
10x 成本节约
Kafka 成本主要由计算和存储两部分构成，AutoMQ 在这两部分的优化理论上已经做到云上成本最优，相比 Apache Kafka 有 10x 的成本节约：
计算
Spot 实例节省至多 90%：AutoMQ 得益于 Broker 无状态，可以大规模使用 Spot 实例来节省单节点计算成本。
EBS 多副本高可靠至多节省 66%：AutoMQ 基于 EBS 的多副本来保障数据高可靠，相比 ISR 三副本，计算实例可以至多 1 台顶 3 台。
Auto Scaling：AutoMQ 采用目标跟踪策略，根据集群流量实时进行集群的扩缩。
存储
- 对象存储节省至多 93%：AutoMQ 将几乎所有的数据存储在对象存储中，相比 3 副本 EBS，可以至多节省 93% 的存储成本；
固定规模
AutoMQ 极限吞吐是 Apache Kafka 的 2x，发送耗时 P999 为 Apache Kafka 的 1 / 4。
测试
本测试测量 AutoMQ 和 Apache Kafka 在相同集群规模下，不同流量规模的的性能和吞吐上限。测试场景如下：
集群部署 23 台 Broker，创建 1 个 1000 分区的 Topic。
分别启动 500 MiB/s、1 GiB/s 的 1:1 读写流量；此外额外测试二者的极限吞吐（AutoMQ 2200 MiB/s， Apache Kafka 1100 MiB/s）。
Apache Kafka 每台 broker 额外分别挂载一块 500GB 156MiB/s gp3 EBS 用于存储数据。
驱动文件：apache-kafka-driver.yaml，automq-for-kafka-driver.yaml
负载文件：tail-read-500m.yaml，tail-read-1024m.yaml，tail-read-1100m.yaml，tail-read-2200m.yaml
AutoMQ 安装配置文件：tail-read.yaml
| 对比项 | 极限吞吐 | 500 MiB/s 发送耗时 P999 | 1 GiB/s 发送耗时 P999 |
|---|---|---|---|
| AutoMQ | 2200 MiB/s | 13.829 ms | 25.492 ms |
| Apache Kafka | 1100 MiB/s | 55.401 ms | 119.033 ms |
发送耗时和 E2E 耗时的详细数据：
| Pub Latency(ms) | 500 MiB/s | 500 MiB/s | 1 GiB/s | 1 GiB/s | 吞吐上限 | 吞吐上限 |
|---|---|---|---|---|---|---|
| Pub Latency(ms) | AutoMQ | Apache Kafka | AutoMQ | Apache Kafka | AutoMQ 2200 MiB/s | Apache Kafka 1100 MiB/s |
| AVG | 2.116 | 1.832 | 2.431 | 3.901 | 5.058 | 4.591 |
| P50 | 1.953 | 1.380 | 2.118 | 2.137 | 3.034 | 2.380 |
| P75 | 2.271 | 1.618 | 2.503 | 3.095 | 3.906 | 3.637 |
| P95 | 2.997 | 2.618 | 3.859 | 8.254 | 9.555 | 10.951 |
| P99 | 6.368 | 12.274 | 8.968 | 50.762 | 37.373 | 60.207 |
| P999 | 13.829 | 55.401 | 25.492 | 119.033 | 331.729 | 134.814 |
| P9999 | 32.467 | 76.304 | 65.24 | 233.89 | 813.415 | 220.280 |
| E2E Latency(ms) | 1 GiB/s | 1 GiB/s | 吞吐上限 | 吞吐上限 |
|---|---|---|---|---|
| E2E Latency(ms) | AutoMQ | Apache Kafka | AutoMQ 2200 MiB/s | Apache Kafka 1100 MiB/s |
| AVG | 4.405 | 4.786 | 6.858 | 5.477 |
| P50 | 3.282 | 3.044 | 4.828 | 3.318 |
| P75 | 3.948 | 4.108 | 6.270 | 4.678 |
| P95 | 10.921 | 9.514 | 12.510 | 11.946 |
| P99 | 26.610 | 51.531 | 34.350 | 60.272 |
| P999 | 53.407 | 118.142 | 345.055 | 133.056 |
| P9999 | 119.254 | 226.945 | 825.883 | 217.076 |
分析
- 相同集群规模下， AutoMQ 的极限吞吐是 Apache Kafka 的 2 倍
AutoMQ 基于 EBS 底层的多副本来保障数据高可靠，上层无多余的复制，而 Apache Kafka 需要通过 ISR 三副本来保障数据高可靠。在不考虑 CPU 和网络瓶颈下，AutoMQ 和 Apache Kafka 都跑满硬盘带宽，AutoMQ 的理论吞吐上限是 Apache Kafka 的 3 倍。
在本测试中，AutoMQ 因为需要上传数据到 S3，CPU 使用率相比 Apache Kafka 更高，AutoMQ CPU 先到瓶颈。23 台 r6in.large 总硬盘带宽上限 3588 MB/s，Apache Kafka 三副本理论发送极限为 1196MB/s，Apache Kafka 硬盘先到瓶颈。最终压测的极限吞吐 AutoMQ 是 Apache Kafka 的 2 倍。
- 相同集群规模和流量（500 MiB/s）下，AutoMQ 的发送延迟 P999 是 Apache Kafka 的 1 / 4，即使在 AutoMQ 在两倍（500 MiB/s : 1024 MiB/s）的流量下，发送延迟 P999 仍是 Apache Kafka 的 1 / 2。
AutoMQ 使用 Direct IO 绕过文件系统直接写 EBS 裸设备，无文件系统开销，可以获得比较稳定的发送延迟。
Apache Kafka 通过 Buffered IO 将数据写到 page cache ，写到 page cache 后就返回成功，由操作系统在后台将脏页刷到硬盘。文件系统开销、消费冷读和 page cache 缺页的不确定性均可能导致发送延迟的抖动。
- 换算到 1 GiB/s 的吞吐，AutoMQ 相比 Apache Kafka 有至多 20x 的计算降本和 10x 的存储降本。
计算：AutoMQ 只用 EBS 作为 S3 的写入缓冲区，在关机时就会将数据上传到 S3，30s 内完成关机下线。因此 AutoMQ 可以充分使用 Spot 实例。Spot 实例相比 On-Demand 实例至多便宜 90%，加上 AutoMQ 单机吞吐是 Apache Kafka 的 2 倍，最终 AutoMQ 相比 Apache Kafka 最多有 20x 的计算降本。
存储：AutoMQ 几乎所有数据都在 S3，S3 按照实际存储的数据量来收费。Apache Kafka 基于硬盘三副本存储数据，通常生产环境中会额外预留至少 20% 的硬盘空间余量。AutoMQ 相比 Apache Kafka 每 GB 的存储费用最多有 1 / （S3 单价 0.023 / （3 副本 * 0.08 EBS 单价 / 0.8 硬盘水位）） = 13x 的降本，附加上 S3 API 调用的成本，最终 AutoMQ 相比 Apache Kafka 至多有存储降本 10x。
另外 Apache Kafka 极限吞吐压测的已经把硬盘带宽占满，实际生产环境中需要预留硬盘带宽给分区迁移和冷数据追赶读，写入水位上限会设置得更低。而 AutoMQ 因为追赶读是从 S3 读取数据使用的是网络带宽，读写分离，硬盘带宽可以全部用于写入，实际生产的水位上限和压测保持一致。
Auto Scaling
11x 极致降本，AutoMQ 充分利用 Auto Scaling 和对象存储，实现真正的计算和存储按量付费。
测试
本测试模拟生产峰谷负载，测量 AutoMQ 在 Auto Scaling 目标跟踪策略下的成本和性能表现。测试场景如下：
通过 AutoMQ Installer 在 AWS 上安装集群。
创建 1 一个 256 分区、保存时间为 24 小时的 Topic。
以如下 1:1 读写的动态流量进行压测：
常时流量为 40 MiB/s。
从 12:00 到 12:30 流量上升至 800 MiB/s， 到 13:00 流量回归至 40 MiB/s。
从 18:00 到 18:30 流量上升至 1200 MiB/s， 到 19:00 流量回归至 40 MiB/s。
驱动文件：apache-kafka-driver.yaml，automq-for-kafka-driver.yaml
负载文件：auto-scaling.yaml
AutoMQ 安装配置文件：auto-scaling.yaml
相同负载下，AutoMQ 和 Apache Kafka 成本对比：
| 成本类别 | Apache Kafka (USD / month) | AutoMQ (USD / month) | 倍率 |
|---|---|---|---|
| 计算 | 3,054.26 | 201.46 | 15.2 |
| 存储 | 2,095.71 | 257.38 | 8.1 |
| 合计 | 5,149.97 | 458.84 | 11.2 |
分析
本测试是在 AWS 美东实测的的一个成本账单，计算和存储都做到了按量付费：
计算：计算节点在 Auto Scaling 的目标跟踪策略下，根据集群流量动态扩缩，分钟级将集群水位控制在 80% （AWS 的监控报警进度是分钟级，加上监控的延迟，跟踪精度是 2 分钟左右）。
存储：存储的数据几乎都在 S3 上，存储费用主要由 S3 存储费用和 S3 API 调用费用组成。S3 存储费用和数据的写入量和数据保存时间正相关，S3 API 调用费用和写入量正相关。S3 存储费用和 S3 API 调用费用均是按量付费。
如果用 Apache Kafka 搭建三副本集群来服务日常峰值 1 GiB/s 的流量，在相同流量模型下，Apache Kafka 需要每月花费至少：
计算：难以动态伸缩，需要为峰值准备容量，Broker 花费 r6in.large 单价 $0.17433 每小时 * 730 小时每月 * 23 台 = $2927.00。
存储：
存储费用：（总数据量 6890.625 GB x 3 副本 / 硬盘水位 80%） x EBS 单价 $0.08GB 每月 = $2067.19。
存储带宽费用：MB 带宽单价 $0.04 x 额外购买带宽 31MB/s x 23 个 EBS 卷 = $28.52。
| 成本类别 | 成本类别 | Apache Kafka (USD / month) | AutoMQ (USD / month) | 倍率 |
|---|---|---|---|---|
| 计算 | Controller | 127.26 | 127.26 | 1.0 |
| 计算 | Broker | 2,927.00 | 74.20 | 39.4 |
| 计算 | 合计 | 3,054.26 | 201.46 | 15.2 |
| 存储 | EBS Storage | 2,067.19 | 0.43 | - |
| 存储 | EBS Throughput | 28.52 | - | - |
| 存储 | S3 Storage | - | 158.48 | - |
| 存储 | S3 API | - | 98.47 | - |
| 存储 | 合计 | 2,095.71 | 257.38 | 8.1 |
| 合计 | 合计 | 5,149.97 | 458.84 | 11.2 |
总结
本次基准测试展现出 AutoMQ 在基于云重塑 Kafka 后相比 Apache Kafka 在效率提升和成本节约上均有不错的优化：
100x 效率提升：
在分区迁移场景，AutoMQ 30GB 分区迁移时间从 Apache Kafka 12 分钟 下降到 2.2 秒，达到了 300x 效率提升。
极致弹性，AutoMQ 0 -> 1 GiB/s 仅需 4 分钟就能自动 Scale-out 满足目标容量。
在历史数据追赶读场景，AutoMQ 读写分离不仅平均发送延时有 200 倍的优化从 800ms 下降到 3ms，而且追赶读吞吐是 Apache Kafka 的 5 倍。
10x 成本节约：
在固定规模下，AutoMQ 的吞吐上限高达 2200 MiB/s，为 Apache Kafka 的 2 倍。同时发送耗时 P999 仅为 Apache Kafka 的 1 / 4。
在 40 MiB/s ～ 1200 MiB/s 动态负载场景下，AutoMQ 通过 Auto Scaling 自动弹性伸缩在低峰期节省了大量的计算资源，实测 AutoMQ 相比 Apache Kafka 实现了 11x 的账单降本。