AutoMQ BYOC（FSx WAL）· 撮合订单总线场景实测 —— 技术交流材料

致 AutoMQ 团队：这是我们在 AWS 东京区对 AutoMQ 商业版（BYOC，FSx for ONTAP WAL）做的一轮系统实测的整理。 目的是交流与请教：把我们看到的现象、复现条件和数据完整摆出来，请贵方指出我们在用法 / 配置上的不当之处， 并对其中的疑似缺陷给出解释、规避或修复计划。

口径：「实测」= 结果文件里的数字或 broker 日志原文；「我们的理解」= 推测，单独标出，欢迎纠正。 每个问题都给出复现条件；所有消息都做了逐条审计（丢失 / 乱序 / 重复），全部测试中未发现已确认消息丢失。

测试时间：2026-10-28 – 11-08 · 版本：控制台 8.4.7 → 8.4.8-aws，数据面 5.5.6 → enterprise-core 5.5.7（Kafka 3.9.1）。

目录

1. 一页摘要
2. 评估场景与门槛
3. 测试环境
4. 测试方法
5. 测试覆盖
6. 正面结果
7. 需要交流的问题（7.1 双 FSx 专章 · 7.2 Q28 · 7.3 FSx 首选 AZ · 7.4 Q29 · 7.5 S3 · 7.6 灰色故障 · 7.7 kill -9 · 7.8 客户端规避的代价 · 7.9 运维与配置 · 7.10 部署与文档）
8. 5.5.7 已不再复现的问题
9. 问题清单汇总
10. 建议的交流方式与我们能提供的材料

• 附录 A：客户端变体与术语 · 附录 B：开源版的两个观察

1. 一页摘要

我们测了什么：把 AutoMQ 商业版当作撮合 / 交易系统的订单总线来评估——单分区与多分区、acks=all + 幂等、开环定速订单流， 1k–200k msg/s 速率阶梯、1–4 h 浸泡，以及十余类故障与运维事件（进程崩溃、受控重启、AZ 网络分区、AWS FIS 模拟 AZ 级故障、 FSx HA 切换、broker ↔ FSx 灰色故障、S3 不可用、扩缩容、在线升级、单 FSx / 双 FSx）。

稳态表现很好：5.5.7 单分区 4 h 浸泡 288 M 条，p99 7.87 ms、p99.99 32.65 ms，0 丢 / 0 失败；客户端调优后单分区 200k msg/s、p99 8.66 ms； 在线升级、在线扩缩、FSx 备份 / 扩 IOPS / 扩 SSD 都几乎无感；broker 实例被停后 BYOC 约 1.7 min 自动拉起替换实例。

希望重点交流的 5 件事（详见 §7）：

我们希望得到的：对每个问题，①是否为预期行为 / 已知问题；②正确的配置或用法；③若是缺陷，修复版本与时间； ④我们可以在新版本上按同一套方法复测并回传结果。

2. 评估场景与门槛

场景：撮合引擎的订单入口总线。要求同一 key（交易对 / 账户）严格有序、已确认消息零丢失、任何单点故障下停写尽量短且能自动恢复。 生产端为长连接网关（幂等生产者，acks=all），典型为单分区（严格全序）或少量分区。

我们用的评估门槛（项目内部建议值，供理解数据的含义；不是对产品的通用要求）：

「停写」一律指订单流最长连续零确认秒数；「最大确认」是单条消息最长确认时间，二者不同，下文分开写。

3. 测试环境

4. 测试方法

4.1 订单流模型

4.2 逐条审计的定义

4.3 故障注入

公共负载：三路审计订单流（三个 AZ 的客户端，各 5k msg/s × 200 B），注入前 130 s 稳态、注入后保持并在 finally 中撤销，每路 900 s + drain； 相邻故障间隔 ≥ 300 s；故障后对各 topic 做写入探测，判断是否自愈。

4.4 数据有效性纪律

• 单变量：两组对照只差一个变量（客户端超时、幂等、in-flight、单 / 双 FSx、版本）。
• 复测：关键结论至少 2 次；单次离群必须复测；结论里写明「n 次中 m 次」。
• 放置校验：自动均衡会改掉手工放置（见 Q8），放置敏感测试前后都校验 leader 位置，不符即重新钉位并作废该组。
• 作废规则：重叠运行、放置漂移、注入实际时长与名义不符、网络路径异常（如 WAL 绕行 NAT，见 Q15）的结果全部作废重跑，不进本文。

5. 测试覆盖

6. 正面结果

7. 需要交流的问题

每节格式：现象 → 复现条件 → 实测数据 → 日志原文 → 我们的理解（推测）→ 想请教。编号沿用我们此前材料中的 Q 编号，便于对照。

7.1 双 FSx（file_system_count = 2）—— 专章

背景：针对「FSx 是 WAL 单点」，贵方建议组合两个 FSx cluster。我们在 5.5.7 + 控制台 8.4.8 上部署了双 FSx（apply 1,834 s）， 三台 broker 同时挂载两套 /wal，两套 FSx 的首选子网都在 az2。下表是同一 harness 下单 FSx 与双 FSx 的对照：

D2 / D3 中 broker 日志里没有 Q20 / Q21（5.5.6 的 kill -9 长尾）的特征，我们认为这是另一种故障模式。

Q30 细节（双 FSx 缩回单 FSx）

• 操作：file_system_count 2 → 1（terraform plan 显示 in-place、0 destroy），对应控制台 Task 99。
• 现象：step 0–11 在 10:55:34–36Z 完成；step 12 RefreshNodeForFileSystemTaskStep 每 5 s 轮询，≥ 3 h 不结束，没有 WARN / ERROR。 az2 的 broker 1 自 12:17:42Z 起启动即致命退出，13:55Z 前累计 1,266 次（约 32 s 一次）。其余 2 台继续服务，0 个不可用分区。
• 日志原文：

  Exiting Kafka due to fatal exception during startup … NullPointerException: Cannot invoke "java.lang.Long.longValue()"
    because the return value of "java.util.NavigableMap.floorKey(Object)" is null
  [CONFIRM_WAL-1-…] Using the old config NodeMetadata{nodeId=1, … walConfig='0@any://?walID=2,2@nfs:///mnt/nfs/2?iops=1000&iodepth=4'} for recovering
  新配置：s3.wal.path = 0@any://?walID=1&walID=2,1@nfs:///mnt/nfs/1…,2@nfs:///mnt/nfs/2…
  

• 回退：plan 显示控制台仍记为 2 套 ⇒ 改回 2 是 no-op，没有 API 回滚路径。最终只能删除实例重建（控制台在挂起状态下接受删除，40 min，实例内数据丢弃）。 扩容 1 → 2（约 9 min）正常。

我们的理解（推测）：file_system_count = 2 是 WAL 的负载分摊，不是健康感知的故障切换——每台 broker 同时依赖两套 FSx（NFS hard 挂载）， 其中一套不可达时，写到它上面的 WAL 被阻塞而不是被避开，故障面从 1 套变成了 2 套；两套首选节点同 AZ，也没有 AZ 冗余。 缩容时 broker 恢复阶段读到旧的 WAL 映射，与新配置不一致。

想请教：

1. 双 FSx 的设计目标是什么——吞吐 / 尾延迟分摊，还是可用性？如果是后者，D1 / D2 / D8 的表现是否符合预期？
2. 是否有（或计划）「WAL 自动避开不可达的 FSx」的能力？需要什么配置？
3. D2 / D3 故障撤销后，为什么部分分区持续不可写、需要受控重启？对应的日志特征与修复？
4. 两套 FSx 的首选节点能否由控制台分到不同 AZ？
5. 双 FSx 下计划内 HA 切换为什么比单 FSx 停顿更长？
6. FSx 2 → 1 缩容是否受支持？若支持，正确步骤是什么；若不支持，控制台为何接受该变更、且不报错不回滚？Q30 的修复计划？
7. 在贵方的推荐架构里，撮合类场景要消除 FSx 单点，应该怎么部署？

7.2 Q28 —— FSx 首选 AZ 短暂分区后，长连接幂等生产者永久写不进去

• 现象：FSx 首选 AZ（az2）网络分区约 60–80 s 后，存活的幂等生产者被 broker 持续判为序号乱序，既不接受写入、也不返回可恢复的错误， 该生产者每条都超时，直到运行结束都没恢复。分区本身可写：同一时刻新建的生产者 0 s 就能写。
• 复现条件：客户端 delivery.timeout.ms=30000（附录 A 的 rt5）。「批次过期」是必要条件但不充分：默认超时下一次停写 124–125 s 也有批次过期，但没有卡死。
• 实测：

丢失全部为 0。broker 日志：对相关分区持续打印 [OUT_OF_ORDER] processing append operation（ElasticReplicaManager），单分区每次运行约 34 次。

• 我们试过的规避及代价：
  • delivery.timeout.ms=120000（rt5d）：不再永久卡死，但 5.5.7 多分区停写约 126 s（失败 104,294）；单分区停写 249 s（失败 185,154）。
  • 关幂等 + in-flight 1：不再永久卡死，但三路仍停写 133–139 s，「报失败但已写入」升高，且关幂等后重试理论上会产生重复。
  • 双 FSx：不缓解。
• 我们的理解：此前沟通中提到 5.5.7 已修复该问题，但我们在 5.5.7 上仍能复现。
• 想请教：① 服务端为何既不接受、也不返回可让客户端恢复的错误（标准 Kafka 的 OUT_OF_ORDER_SEQUENCE_NUMBER / epoch bump 路径）？ ② 请从源码确认确切触发条件与修复版本；③ 与历史 issue #369 / #509 / #584 是否同类？④ 在修复前，是否有不降吞吐、不关幂等的推荐规避？

7.3 FSx 首选 AZ = 全集群故障域

• 现象：FSx 只有一个 HA pair。首选节点所在 AZ 网络不通时（FSx 本身健康，不触发 HA 切换），所有 broker 的 WAL 都不可达，failover 也读不到 WAL，只能等故障解除。
• 实测：
  • NACL 隔离 az2 子网（名义 60 s）：5.5.7 多分区停写 120–146 s，与客户端超时配置无关；rt5d 客户端 126 s、失败 104,294。双 FSx（D6，隔离 64 s）71–74 s。
  • AWS FIS AZ 级组合故障（断 broker 子网 5 min + 停该 AZ broker，单分区，推荐客户端）： 拿掉 az1（非 FSx 首选）× 2 ⇒ 三路零确认 77–81 s、最坏一秒 69.5–72.4 s，0 失败、0 丢，BYOC 约 1.7 min 自动拉起替换实例； 拿掉 az2（FSx 首选子网）× 2 ⇒ 三个 AZ 的生产者全部停写 369–376 s、最坏一秒 300 s、每路 29.9–33.3 万笔失败，0 丢，故障撤销后 0 s 可写。
• 我们的理解：一个 AZ 故障即全集群停写，时长 ≈ 故障时长 + 约 70 s。FSx 的 HA 切换不会因为「客户子网不可达」而触发，所以 FSx 侧不会自救。
• 想请教：是否有（或计划）在失去 FSx 首选节点所在 AZ 时，让 WAL 主动切到备用节点 / 其他 WAL 的机制？推荐的多 AZ 容灾部署是什么？

7.4 Q29 —— 无故障下 CPU 背压限制 Produce，周期性停写

• 现象：多生产者、小请求负载下，broker CPU ≈ 0.9 触发背压，RequestRate 配额被下调，Produce 请求排队超过 request.timeout.ms。
• 复现条件：12 生产者 × 2k msg/s 写 24 分区（单 broker ≈ 5.3–5.7k req/s，m7g.xlarge）；单分区混合负载（3 × 5k + 9 × 1k msg/s + 1 路事务）也触发。 单生产者 20k msg/s 4 h 不触发；12 生产者写单分区约 20k msg/s 不触发。
• 实测：12 生产者 3 / 3 复现，最差一路 max 5.4–8.6 s（干净集群一次 p99 4,787 / max 8,617 ms）；配额最低压到 2,205–2,388。 单分区混合负载 45 min 内 17 段零确认（3–11 s），其中 13 段与背压日志 ±1 s 对齐。0 失败 / 0 丢，应用侧只看到延迟。linger.ms=5 无效。5.5.6 未观察到。
• 日志原文：

  CPUChecker: CPU usage is high … average: 0.90–0.92
  DefaultBackPressureManager: The system is in a HIGH state, checkers: {CPU=HIGH}
  QuotaRegulator: Decrease broker quota Fetch from 536,870,912 to 1.00
  QuotaRegulator: Decrease broker quota RequestRate from 20,000 to 3,981  →  … to 2,388
  

• 想请教：① 背压能否只限 Fetch / 后台任务、豁免 Produce？② 阈值与开关（公开文档未找到）？③ m7g.xlarge 在约 5.3k req/s/broker 时 CPU 0.9 是否符合预期？推荐的机型？

7.5 S3 不可用时写路径停写（5.5.7 与 5.5.6 行为不同）

• 现象：5.5.7 上 S3 不可用约 4 min 后 broker 0 停写、约 7 min 后全集群停写；S3 恢复后还要约 1 min 才恢复。broker 日志摘录中没有错误行。
• 复现条件：broker 实例角色 Deny s3:*。
• 实测：

对照：5.5.6 同条件 300 s 内写路径不受影响（0 失败，max 1.8 s）。停写 ≈ S3 中断时长 − 220 s，S3 中断越久停写越久。

• 我们的理解（推测）：5.5.7 的 WAL 上限 / 回收策略有改动，WAL 在 S3 不可用期间只增不减、触顶后停写。未验证。
• 想请教：5.5.7 在这里改了什么？WAL 容量或 cache 写满时的预期行为（背压 / 拒写 / 报错）？能否恢复 5.5.6 的行为或给出可调上限？

7.6 Q7 —— broker ↔ FSx 灰色故障无自动隔离

• 现象：broker 到 FSx 的 NFS 不通、但心跳正常时，broker 不报错、不 fence、不 failover，WAL IO 一直挂着，故障解除后才报 IO 错误并自行恢复。 同一生产者的缓冲被卡住的分区占满（BufferExhaustedException），健康分区的写入也被拖停。
• 实测：切断 broker 0 → FSx 的 NFS 120 s：5.5.7 停写 149 s，失败 227,892；5.5.6 挂住的 IO 在 elapse=135737ms 后才返回。停写 ≈ 故障时长 + 约 30 s。
• 日志原文：Failed to execute IO operation, elapse=135737ms → WAL is fenced, reason: WRITE_FAILED,err=… Input/output error
• 我们的理解：挂载参数为 nfs4 … hard, sync, timeo=30, retrans=3，FSx 不可达时 I/O 无限期阻塞。
• 想请教：是否有 WAL IO 超时自杀（watchdog）开关？推荐的运维处置（例如主动重启该 broker）是否更快？

7.7 kill -9 后的恢复时长（Q1 / Q2 / Q3 / Q23）

• 实测：5.5.7 kill -9 单 broker 16 次全部自愈：最长零确认 15–27 s，最大确认 18.4–34.2 s（其中 2 次 > 30 s）；+3,000 分区 27.4 s。
• 从进程死亡到发起 failover 约 18 s，而 broker.session.timeout.ms 只有 9 s；把 session 调到 4.5 s（heartbeat 1 s）没有可测收益（kill -9 21.5 s vs 22.9 s；隔离 26.6 s vs 23.5 s）。

  [AZ_FAILOVER] Detected AZ-level failure in 'ap-northeast-1c'. All 1 nodes require failover.
  [ADD_NEW_FAILOVER] nodeId=0, target=2
  

• 5.5.6 曾出现自动拉起与 failover 的竞态：Node epoch expired, fenced or not exist: CommitStreamSetObjectRequestData(nodeId=1 …) → [FAILOVER] fail, retry later； failover 期间 NFS WAL IO 卡 60 s（elapse=60097ms）。5.5.7 默认客户端 kill -9 az2 为 23.5 s，该量级未复现。
• 想请教：① 18 s 中检测之外的约 9 s 花在哪里，能否缩短（推测在等 WAL 租约 / NFS 锁过期，日志中有 Forced lock deletion）？ ② 检测时长在商业版中是否可调、推荐值？③ 竞态是否已在 5.5.7 处理？④ 单 broker 进程崩溃时日志写 AZ-level failure（该 AZ 只有 1 个节点）是否只是措辞（Q10）？

7.8 客户端规避之间的冲突（in-flight 1 与 zone router）

• in-flight：调优配置（in-flight 5 + 256 KiB 批 + zstd）才能达到单分区 200k；而 Q28 的规避需要关幂等 + in-flight 1。 我们测了 in-flight 1 的代价：1k–200k 吞吐全部达标，但 p99 由 7.7–9.1 ms 升到 11.95–13.75 ms（约 +50 %），100k 一档有 1 秒 > 100 ms。 另外 in-flight 3 时 50k 只确认 38,252/s ⇒ 单分区上限 ≈ in-flight × 批大小 ÷ RTT。
• zone router（Q6 / Q19）：开启客户端 zone router（client.id 带 automq_az=）时，转发链上的节点卡住，请求要等满 request.timeout.ms（30 s）， leader 健康的分区也一起停；关闭后同 AZ 健康分区停写 59.8 s → 0.17 s，稳态跨 AZ 写快 0.8–5.1 ms。但服务端 router_channel 写入模式仍在（DEFAULT），客户端关不掉。
• 想请教：① 撮合类场景是否建议关闭 zone router？② router_channel 写入模式能否关闭，是否有 direct 模式、代价是什么？③ FSx WAL 的组提交间隔 / 批大小是多少、可否调（Q12）？

7.9 运维与配置

7.10 部署与文档

8. 5.5.7 已不再复现的问题

如实单列。我们没有拿到修复说明，以下只是「在我们的样本中不再出现」，统计上尚未到确证，希望贵方给出修复说明以便关闭：

9. 问题清单汇总

「影响」只写实测事实；「我们的请求」是希望贵方回复的内容。

10. 建议的交流方式与我们能提供的材料

建议议程（约 90 min）：

1. 我们介绍场景、方法与覆盖（15 min，§2–§5）
2. 双 FSx 专章（25 min，§7.1）
3. Q28 与 FSx 首选 AZ 故障域（20 min，§7.2–§7.3）
4. Q29、S3 不可用、灰色故障（15 min，§7.4–§7.6）
5. 其余问题按清单逐条确认（10 min，§9）
6. 后续：贵方给出修复 / 规避，我们在新版本上按同一方法复测（5 min）

我们能提供的材料（按需，经内部审批后提供）：

• 压测工具 Bench 与故障注入 harness 的源码，以及从零搭建环境的步骤（Terraform + 脚本）；
• 每个问题对应的运行清单、每秒时间线与审计结果；
• 相关时段的 broker / controller / state-change 日志与控制台任务日志摘录（含 Q28、Q30、D2 / D3 的原始日志）；
• 新版本发布后，我们可以按本文同一套方法复测并回传结果。

附录 A：客户端变体与术语

附录 B：开源版的两个观察

我们也测了 AutoMQ 开源版 1.7.4（S3 WAL），这两点供参考：

• X8：写确认 p50 恒为约 355–373 ms，客户端调不动（调批 + zstd 后吞吐能跟上 20k / 50k / 100k，但 p50 不变）。我们理解这是 S3 WAL 组提交间隔决定的，属架构特征。
• X9（疑点，未验证）：单客户端 acks=all 60.1 MB/s，acks=1 547.3 MB/s，相差约 9 倍；RF=1 时两者理论上应等价。按请求耗时推算，acks=1 的应答早于一次 S3 WAL 写入完成。 想确认：开源版 acks=1 是否在 WAL 持久化之前就应答？

本页由 Markdown 原文生成（同一份内容，无删改）。