AutoMQ与AWS FSxN性能优化实践

1. AutoMQ与AWS FSxN性能测试背景解析

AutoMQ作为新一代云原生消息队列服务，其核心创新在于彻底重构了传统Kafka的存储架构。传统Kafka采用本地磁盘存储数据并通过跨可用区（AZ）复制实现高可用，这种设计在云环境下面临两大痛点：首先是跨AZ网络流量成本高昂，其次是存储与计算强耦合导致的弹性不足。

AutoMQ的突破性设计体现在三个层面：

1. 存算分离架构：将数据持久化层完全卸载到S3对象存储，计算节点无状态化
2. 共享存储优化：引入AWS FSx for NetApp ONTAP（FSxN）作为WAL（Write-Ahead Log）存储介质
3. 流量成本归零：通过FSxN的多AZ共享特性，消除跨AZ数据复制流量

这种架构演进使得AutoMQ在保持Kafka协议兼容性的同时，实现了成本与性能的平衡。特别是在2025年12月发布的版本中，通过深度集成FSxN，成功将端到端延迟从传统方案的数百毫秒降低到10毫秒以内，达到了与本地SSD相当的性能水平。

技术提示：WAL（预写式日志）是消息系统的关键组件，所有写入请求会先持久化到WAL，再异步应用到后端存储。选择高性能WAL存储对保证数据可靠性和低延迟至关重要。

2. 测试方法论与场景设计

2.1 延迟构成要素拆解

在消息系统中，客户端感知的端到端延迟由多个环节组成：

code复制客户端视角延迟 = 生产者攒批时间 + 网络传输时间 + 服务端处理时间 + 副本同步时间

传统Kafka架构中，后三个环节都涉及跨AZ通信，不仅产生网络延迟，还会带来显著的流量成本。AutoMQ通过FSxN共享存储重构了这个流程：

1. 网络传输：客户端直接写入本AZ的FSxN卷，避免跨AZ传输
2. 服务端处理：计算节点从本地挂载的FSxN卷读取数据
3. 副本同步：通过FSxN的跨AZ数据同步机制实现，无额外网络开销

2.2 测试场景设计

为全面评估性能表现，我们设计了两个互补的测试场景：

2.2.1 极限性能基准测试

• 目标：测量系统理论性能上限
• 参数配置：
  • linger.ms=0（禁用生产者批处理）
  • batch.size=64KB
  • 禁用压