AutoMQ 共享存储架构
AutoMQ 将 WAL 与保留数据的存储分离。Broker 先将收到的记录持久化到 WAL，再上传至对象存储，因此 WAL 和保留数据可以分别选择底层存储服务。 本次 Azure 部署使用 Azure Zone-redundant Disk 承载 WAL，以 Azure Blob Storage 保存保留期内的数据。存储架构详情请参阅 WAL 存储。Azure 部署配置
Azure 区域冗余存储（ZRS）在三个可用区（AZ）之间同步复制托管磁盘数据。在本次部署中，每个 Broker 使用一块开启 ZRS 的 Premium SSD 承载 WAL，Azure Blob Storage 则保存保留期内的数据。 跨可用区同步复制会增加 WAL 写入路径的延迟。服务的复制和恢复机制请参阅 Azure 托管磁盘冗余。 主要集群测试部署在 Azure Kubernetes Service（AKS）上，配置如下：
P10、P15 和 P20 是 Azure Premium SSD 的三个规格档位。更高档位同时提供更大的容量和更高的基准 I/O 性能：
WAL 本身只需要数 GiB 空间。主要测试选择 P20 是为了获得所需的 I/O 性能，而非用它保存保留期内的 Kafka 数据。虚拟机和磁盘都存在 I/O 上限：D4as v5 的文档标明，其 Premium SSD 非缓存吞吐在不使用突发能力时上限为 144 MB/s。复测时应同时核对 Dasv5 虚拟机规格和 Premium SSD 档位。
测试配置
测试使用 AutoMQ 开源项目自带的性能测试工具 automq-perf-test.sh。该工具参考 OpenMessaging Benchmark 的核心逻辑实现，可以在单个进程中运行多个 Producer 和 Consumer，统计写入和消费吞吐、写入延迟及端到端延迟的各分位数。使用方式和负载配置请参阅 AutoMQ 性能测试。 本次负载固定记录大小为 64 KiB，并关闭 Producer 批处理，以减少客户端批处理策略带来的差异。这些结果不代表逐条发送小消息时的延迟。
写入延迟指收到写入确认所需的时间，端到端（E2E）延迟还包含消费过程。Azure 服务规格使用十进制 MB/s，下文实测吞吐使用二进制 MiB/s。
在 Azure AKS 上部署 AutoMQ 后，可以使用以下命令作为主要集群测试的起始负载。将 bootstrap 地址替换为实际集群端点。
测试结果
高吞吐集群测试
15 个 Broker 的 D4as v5 / P20 集群以 16,640 条/秒为目标，即 1,040 MiB/s，约 1 GiB/s。实测平均写入和消费吞吐均为 778.09 MiB/s，写入错误数为零。
写入延迟的中位数为 8.125 ms，P99 为 27.538 ms。更高分位数显示了间歇性延迟尖峰，延迟敏感业务需要同时关注这些长尾数据。
120 MiB/s 下的 WAL 磁盘对比
P10 和 P15 测试均使用 E2as v5 虚拟机、一个含 96 个分区的 Topic、24 个 Producer，以及同一 Consumer group 中的 24 个 Consumer。记录大小为 64 KiB，两组实测写入和消费吞吐均为 120.05 MiB/s。
在相同吞吐下，P15 配置的平均延迟和 P99 更低。P15 和 P10 的平均写入延迟分别为 6.909 ms 和 7.996 ms，写入 P99 分别为 18.398 ms 和 21.597 ms。P10 测试的 WAL 队列深度为 16，IOPS 限制为 400。
150–180 MiB/s 的补充测试
这组测试使用 128 GiB WAL 磁盘，队列深度为 16，IOPS 限制为 400。负载分别在约 150 MiB/s 下运行两次，在 180 MiB/s 下运行一次。
在约 150 MiB/s 的两次测试中，平均写入延迟分别为 9.121 ms 和 8.773 ms，E2E P99 分别为 38.114 ms 和 60.041 ms。在 180.05 MiB/s 下，平均写入延迟为 10.831 ms，E2E P99 为 44.476 ms。
300 MiB/s 下的分区数与客户端并发
两次 D4as v5 / P20 测试均以 300 MiB/s 为目标，每秒发送 4,800 条 64 KiB 记录。第二组同时将分区数和 Producer、Consumer 并发数翻倍。
配置 A 和配置 B 的平均 E2E 延迟分别为 8.101 ms 和 7.647 ms，E2E P99 分别为 21.261 ms 和 21.853 ms。两组配置的 WAL 队列深度均为 32，IOPS 限制为 1,000。