⇄ 撮合引擎订单总线 · AWS 东京区同场实测

撮合订单总线
AutoMQ 商业版 vs Amazon MSK

作为撮合订单总线，AutoMQ 商业版 5.5.7 仍不适合 —— kill -9 长尾已不再复现，但单分区下 FSx 首选 AZ 一次 80 s 的网络分区就让订单流停写数分钟、3 次中 2 次有生产者永久卡死（Q28 未修复，双 FSx 下照样），多生产者并发时 broker 自带的 CPU 背压会无故障地每 ≈ 5 min 卡写入 3–8 s（Q29），S3 不可用时停写 106–136 s（5.5.7 回归），厂商建议的双 FSx 实测不能消除 FSx 单点；MSK Standard 有条件适合（单分区延迟最低、尾部最稳、全部故障自愈，条件是维护窗口避开交易时段）；MSK Express 有条件适合（维护停写最短最稳定；条件是单分区 p99 比 Standard 高约 3–5 ms、1 h 浸泡 max 239 ms，客户端须调 batch + zstd）。

先看判据表综合评估
写入确认 p99（单分区，200 B，1k msg/s，三家同为 m7g.xlarge 级、各自调优后的最优配置）测试记录 §11（r4）
0 ms2 ms4 ms6 ms8 ms10 ms12 ms14 ms4.58 ms7.83 ms7.96 ms
  • MSK Standard · 4.58 ms
  • AutoMQ 5.5.7 · 7.83 ms
  • MSK Express · 7.96 ms
单次故障的最长停写 / 最大确认（对数刻度）测试记录 §8.8 / §8.18 / §10.4 / §10.6 / §10.13 / §10.23；同一订单流 harness，各取最坏样本
1 s10 s1 min5 min30 min5.7 s15–27 s37 s106–136 s249 s573 s≥ 770 s
  • MSK Express 受控重启 · 5.7 s
  • AutoMQ kill -9（16 / 16 自愈）· 15–27 s
  • MSK Standard 配置滚动（单分区混合负载）· 37 s
  • AutoMQ S3 不可用 300 s · 106–136 s
  • AutoMQ FSx 首选 AZ 分区（单分区，delivery 120 s）· 249 s
  • AutoMQ 双 FSx 失去一套 FSx 5 min（须人工重启）· 573 s
  • AutoMQ Q28 单分区 delivery 30 s（生产者永久卡死）· ≥ 770 s
  • 场景只有一个：撮合引擎的订单总线（网关 → 撮合的输入流、撮合输出日志、成交回报）。判断只看三件事：延迟（到 p99.9 / max）、高可用（单次故障停写多久、能否自愈）、吞吐（单分区能写多快）。
  • 单分区是业务场景（同一 symbol / 同一撮合分片必须严格有序，常见单 topic 单分区）；多分区是大数据场景（24 分区订单 topic、多网关并发）。两种都测，结论分开给。
  • 版本：AutoMQ 商业版 BYOC 控制台 8.4.8 + 数据面 5.5.7（11-02 由 5.5.6 在线升级，厂商称修复了此前全部缺陷），3 × m7g.xlarge + FSx for ONTAP Multi-AZ（WAL）；MSK Standard（Kafka 4.1）与 MSK Express（Kafka 4.2）：延迟 / 吞吐（r4，11-07）为 3 × kafka.m7g.xlarge / 3 × express.m7g.xlarge，故障测试（11-07 前）为 3 × *.m7g.large。AWS 东京区 3 AZ，客户端每 AZ 一台。
  • 方法：acks=all + 幂等，开环定速，延迟从计划发送时刻算；消费端逐条审计丢失 / 乱序 / 重复 / 「报失败但已写入」。各系统用各自最优客户端参数：延迟 / 吞吐（r4）三家都用 batch.size 256 KiB · zstd（level 1），AutoMQ 另加 in-flight 5 · linger 1 · 关 zone router · request 5 s · delivery 120 s，MSK in-flight 1 · linger 0；故障测试（11-07 前）为默认 16 KiB 批、不压缩。「测试记录 §」= 实测记录节号，原始结果可应要求提供。
Verdict

结论先行

产品 判定 决定性理由
AutoMQ 商业版 5.5.7 ❌ 不适合 单分区遇 FSx 首选 AZ 分区停写数分钟、3 次中 2 次永久卡死（Q28）；多生产者无故障也周期停写（Q29）；S3 故障波及写路径；丢掉 FSx 首选 AZ（FIS 近似注入）⇒ 三个 AZ 全停 369–376 s、每路 ≈ 30 万笔失败；双 FSx 缩回单 FSx 致 broker 永久下线、只能重建（Q30）
MSK Standard ⚠️ 有条件 延迟最低、尾部最稳、全部自愈；维护停写 0.7–37 s，随负载放大（受控重启 xlarge 另测 1.10–2.24 s，与 large 一致），须避开交易时段，磁盘容量须告警；AZ 网络故障 ≈ 1 min 停写、8 次中 4 次二次停写（FIS 近似注入：broker 回来后 leader 被交还给仍断网的它）；客户端 request 5 s + delivery 120 s 可让报失败降为 0 但缩短不了停写，服务端 leader.imbalance.per.broker.percentage=100 实测不能消除二次停写（§12.5）⇒ 预案须含主动迁 leader：实测断网 +10 s 由运维迁走 leader，最坏一秒降到 7.4–11.8 s、0 失败 0 丢失（E4，2 次，§13）
MSK Express ⚠️ 有条件 维护停写最短最稳（2–10 s，11-07 前 express.m7g.large 一轮）；单分区 p99 比 Standard 高约 3–5 ms（r4 1k：7.96 vs 4.58 ms），1 h 浸泡 max 239 ms；客户端须调 batch + zstd；AZ 网络故障（FIS 近似注入）时部分消息被卡 1.5–2 min（最坏一秒 89.9–117.7 s，期间仍有确认）

AutoMQ 关键问题的数据见 §11.5，故障全表见 §11.4，双 FSx 见 §11.7。

判据表（✅ 合适 · ⚠️ 有条件 · ❌ 不合适 · — 不可测；SP = 单分区，MP = 多分区）：

判据（门槛） AutoMQ 5.5.7 MSK Standard MSK Express
数据安全（已确认 0 丢 / 0 乱序 / 0 重复） ✅ 全部 run 0 / 0 / 0（含 Q28 卡死、S3 900 s） ✅ ✅
SP 稳态延迟（p99 ≤ 10 ms，1k–20k msg/s；r4，m7g.xlarge 级，各自最优配置） ✅ p50 6.25–6.71 / p99 7.74–8.07 ms ✅ p50 3.29–3.37 / p99 4.58–4.71 ms ✅ p50 4.21–4.86 / p99 7.96–8.51 ms
MP 稳态延迟（p99 ≤ 20 ms，1k–50k msg/s；11-07 前一轮，MSK *.m7g.large、默认 16 KiB 批，未在 r4 重测） ✅ p50 6.5–7.6 / p99 7.6–15.9 ms ✅ p50 4.3–5.8 / p99 8.3–14.5 ms ⚠️ p50 4.6–7.5 / p99 11–21 ms
浸泡尾部（p99.99 ≤ 50 ms，max ≤ 200 ms；SP 1 h 为 r4 调优，MP 2 h 为 11-07 前） ✅ SP 1 h 33.75 / 88.82 ms；⚠️ MP 2 h 55.85 / 238.7 ms ✅ SP 1 h 15.35 / 27.05 ms；MP 2 h 34.25 / 56.3 ms ⚠️ SP 1 h 48.95 / 239 ms（2 s > 100 ms）；MP 2 h 58.45 / 127.8 ms
多生产者并发（12 生产者，无故障时不停写；11-07 前，MSK *.m7g.large） ❌ MP 2 / 2 停写 5.4–8.6 s；SP 24k 每 ≈ 5 min 3–8 s（Q29 背压） ✅ max 87 ms ✅ max 126–227 ms
单 broker 硬故障（≤ 30 s，自愈） ⚠️ kill -9：SP 15–21 s、MP 15–27 s，16 / 16 自愈（5.5.6 有 3 / 15 次 32–44 min 长尾，5.5.7 未复现） — 不可注入 — 不可注入
受控维护（重启 / 配置滚动 / 换规格，≤ 10 s；11-07 前 MSK *.m7g.large，受控重启 11-08 在 xlarge 重测结果一致，§12.3） ✅ 受控关闭 2.4 s；扩缩 0.1–0.3 s；在线升级 ≤ 2.9 s ⚠️ SP 重启 0.7–2.3 s；MP 重启 2.0–14.2 s、配置滚动 3.4–19.5 s（SP 混合负载 37 s）、换规格 9.7–14.8 s ✅ 重启 1.4–5.7 s、配置滚动 4.3–7.7 s（混合负载 4.5 s）、换规格 5.4–10.1 s
AZ 网络分区（≤ 30 s，自愈） ❌ FSx 首选 AZ：SP 249 s / 永久卡死（Q28）、MP 120–146 s；非首选 AZ 22.7–30 s — 不可比（NACL 只断客户端路径）；AZ 级组合故障的近似注入（AWS FIS，11-08：切断 az1 broker 子网 5 min + 该 broker 下线；不是真实 AZ 断电——MSK 副本复制走服务侧网络，客户切不断）：MSK Standard 最坏一秒 59.9–119.6 s（累计 8 次中 4 次 broker 回来后 leader 被交还给仍断网的它 ⇒ 二次停写；客户端与 leader.imbalance.per.broker.percentage 调整都不能消除，§12.5），MSK Express 最坏一秒 89.9–117.7 s（期间仍有确认、零确认 0–29 s），AutoMQ 商业版 69.5–72.4 s；若丢的是 FSx 首选 AZ，AutoMQ 三个 AZ 的生产者全停 369–376 s、每路 ≈ 30 万笔失败（测试记录 §12.3） — 同左
依赖服务故障（≤ 10 s） ❌ S3 300 s 不可用：停写 106–136 s；⚠️ FSx HA 切换 3–7 s — —
存储单点（单一存储故障不导致全集群停写） ❌ FSx 单点；双 FSx 实测不能消除，失去一套 5 min 还须人工重启（§11.7） ✅ RF 3 ✅ 服务托管
历史回读干扰（写路径 max ≤ 200 ms；11-07 前，MSK *.m7g.large） ⚠️ 257 ms ✅ 47 ms ⚠️ 243 ms
SP 吞吐上限（200 B，调优后各自最优配置，r4 · 均为 m7g.xlarge 级） 200k ✅（p99 8.66 ms）；默认参数 20k 200k ✅（p99 5.84 ms）；默认参数 20k 200k ✅（p99 10.55 ms）；默认参数 50k
Conditions

测试条件与口径

项 AutoMQ 商业版 MSK Standard MSK Express
版本 控制台 8.4.8 · 数据面 5.5.7（对照 5.5.6） Kafka 4.1 · KRaft Kafka 4.2 · KRaft
Broker（延迟 / 吞吐，r4） 3 × m7g.xlarge（每 AZ 一台） 3 × kafka.m7g.xlarge，EBS 400 GiB 3 × express.m7g.xlarge
Broker（故障测试，11-07 前） 同上 3 × kafka.m7g.large 3 × express.m7g.large
客户端（r4 由同一判据选出的最优配置） batch.size 256 KiB · zstd（level 1） · in-flight 5 · linger 1 · 关 zone router · delivery 120 s batch.size 256 KiB · zstd（level 1） · in-flight 1 · linger 0 batch.size 256 KiB · zstd（level 1） · in-flight 1 · linger 0
持久化 FSx for ONTAP Multi-AZ（首选 az2 / 备 az1），NFS hard mount；冷数据 S3 RF 3 · min.insync 2 服务托管
单分区（SP） me-sp-az1：1 分区，leader 钉在 az1 同左 同左（钉 leader 需暂停 IR）
多分区（MP） me-orders：24 分区，8 / 8 / 8 同左 同左
写入速率 1k / 5k / 10k / 20k / 50k / 100k msg/s × 200 B；1 KiB、4 KiB × 5k msg/s；12 生产者；事务 同左 同左

规格：延迟 / 吞吐（r4，11-07）三家同为 m7g.xlarge 级、客户端各自调优；故障测试在 11-07 之前（MSK 为 *.m7g.large、默认客户端）；11-08 在 xlarge 上重测受控重启（结果一致），并新增 FIS AZ 级组合故障（§12.3）。AutoMQ 另加 FSx。MSK 托管服务不能做进程级 kill -9，子网隔离只切断客户端路径（broker 健康、不切换 leader），因此「硬故障 / AZ 分区」两行 MSK 不可比。

Latency

延迟：单分区与多分区，按写入速率

单分区（业务场景） —— 确认延迟 p50 / p99 ms，200 B，速率阶梯每格 120 s，各自由同一判据选出的最优客户端配置（测试记录 §11）：⚠️ = 吞吐跟上但未达低延迟判据

写入（各自最优配置，r4） AutoMQ 5.5.7 MSK Standard MSK Express
1k msg/s 6.71 / 7.83 3.29 / 4.58 4.21 / 7.96
5k msg/s 6.26 / 7.84 3.31 / 4.66 4.83 / 8.26
10k msg/s 6.25 / 7.74 3.31 / 4.71 ⚠️ 4.86 / 8.38
20k msg/s 6.28 / 8.07 3.37 / 4.67 4.84 / 8.51
50k msg/s 6.33 / 8.06 3.46 / 4.82 4.99 / 9.07 ⚠️
100k msg/s 6.50 / 9.10 3.67 / 5.04 5.13 / 9.81
200k msg/s 6.67 / 8.66 4.30 / 5.84 5.30 / 10.55
1 h 浸泡 20k，最优配置（r4）（p99 / p99.99 / max） 7.89 / 33.75 / 88.82 4.63 / 15.35 / 27.05 8.81 / 48.95 / 239（2 s > 100 ms）

调优前一轮（11-07 之前：MSK 为 *.m7g.large、各家默认 / 推荐客户端，§10.12–§10.19、§8.21–§8.22）：

项 AutoMQ 5.5.7 MSK Standard MSK Express
12 生产者同分区（p99 / max） 14.05 / 67 14.75 / 44 30.25 / 227
事务提交 p50（2 条 / 事务） 39.2 31.0 56.2
4 h 浸泡 20k（p99 / p99.99 / max，288 M 条） 7.87 / 32.65 / 235.6 6.88 / 39.55 / 93.4 17.35 / 85.75 / 264.7（51 s > 100 ms）

读法（r4，四家同为 m7g.xlarge 级、客户端各自调优）：单分区上限 AutoMQ 200k（p99 8.66 ms） · Standard 200k（p99 5.84 ms） · Express 200k（p99 10.55 ms）；默认参数（batch 16 KiB、不压缩）下 Standard 只能确认 32,120/s —— 单分区上限主要由客户端批大小与压缩决定，不在 broker。1k 时 p50：AutoMQ 6.71 / Standard 3.29 / Express 4.21 ms（AutoMQ 每条写要过一次 FSx NFS 同步写）。

多分区（大数据场景），调优后（11-08 补全轮，三家 m7g.xlarge 级，batch 256 KiB · zstd level 1） —— 24 分区订单 topic，单生产者 az1，确认延迟 p50 / p99 ms（测试记录 §13）：

写入（多分区，调优后） AutoMQ 5.5.7 MSK Standard MSK Express
1k msg/s 7.08 / 10.15 4.29 / 7.71 4.12 / 8.05
5k msg/s 7.28 / 12.35 5.14 / 8.43 5.22 / 9.72
10k msg/s 7.54 / 13.85 ⚠️ 5.32 / 8.87 5.61 / 11.35
20k msg/s 7.76 / 13.75 5.37 / 9.10 5.93 / 12.95
50k msg/s 7.95 / 14.25 5.50 / 9.55 5.89 / 12.95
100k msg/s 8.21 / 15.75 ⚠️ 5.59 / 10.25 6.08 / 15.25
200k msg/s 8.35 / 17.15 5.87 / 10.35 6.38 / 15.45
12 生产者同写（p50 / p99；max） ❌ p99 4,514 > 2× 1k 基线（确认 1,999/s 已跟上）；43,700 条尾部未确认（审计消费者落后）；max 7,551 ❌ p99 20.05 > 2× 1k 基线（确认 2,000/s 已跟上）；max 48.75 ❌ p99 33.85 > 2× 1k 基线（确认 1,999/s 已跟上）；max 70.93
4 KiB × 5k 7.38 / 13.05 5.28 / 9.29 5.29 / 12.15
扇出 8.40 / 14.85 5.80 / 9.90 6.54 / 13.55

多分区，调优前一轮（§10.3、§10.11、§8.11–§8.12；11-07 前：MSK *.m7g.large、in-flight 1 · linger 0、默认 16 KiB 批不压缩；AutoMQ 推荐客户端）：

负载 AutoMQ 5.5.7 MSK Standard MSK Express
速率阶梯 1k → 50k，p50 / p99 6.5–7.6 / 7.6–15.9 4.3–5.8 / 8.3–14.5 4.6–7.5 / 11–21
1 KiB × 5k，p50 / p99 / max 6.39 / 11.65 / 28 4.97 / 11.75 / 45 6.38 / 17.95 / 48
4 KiB × 5k，p99 / max 14.15 / 29 84.25 / 272 ❌ 过载（p50 5.7 s，须攒批）
12 生产者，p99 / max ❌ 4,916 / 8,576（Q29 背压，§10.16） 39.55 / 87 62.65 / 126
事务提交 p50 64.0 77.6 77.9
2 h 浸泡 20k，p99.99 / max 55.85 / 238.7（7 s > 100 ms） 34.25 / 56.3（0 s） 58.45 / 127.8（4 s）

AutoMQ 5.5.7 稳态延迟与 5.5.6 相同（§10.3）。

Availability

高可用：故障矩阵（单分区 / 多分区）

单次故障的最长零确认（停写），同一订单流 harness；AutoMQ 为 5.5.7（推荐客户端），MSK 为 in-flight 1 · linger 0（11-07 前 *.m7g.large；末两行为 11-08 xlarge / FIS）：

故障 AutoMQ 单分区 AutoMQ 多分区 MSK Standard MSK Express
AZ 级组合故障（FIS 近似注入，11-08）：broker 所在 AZ 子网切断 5 min + 该 broker 下线 az1：最坏一秒 69.5–72.4 s；FSx 首选 AZ（az2）：三个 AZ 全停 369–376 s、每路 ≈ 30 万笔失败 — 最坏一秒 59.9 / 119.6 s（8 次中 4 次二次停写：leader 被交还给仍断网的 broker；推荐客户端 request 5 s · delivery 120 s ⇒ 0 报失败、停写仍 33–56 s；leader.imbalance.per.broker.percentage=100 不能消除，§12.5） 最坏一秒 89.9–117.7 s（零确认 0–29 s，期间仍有确认）
受控重启（xlarge 重测，11-08） — — SP 1.10 / 2.24 s SP 2.29–2.61 s
kill -9 leader 所在 broker 15 / 21 / 20 s（3 次）；非 leader broker 0 s 15–27 s（12 次）；连杀两台 27.6 s；controller 27.8 s — 不可注入 — 不可注入
受控重启 / 关闭 — stop-ec2 2.4 s SP 0.7 / 2.3 / 1.2 s；MP 2.0–14.2 s SP 1.4–3.2 s；MP 2.1–5.7 s
配置滚动 — — MP 3.4 / 19.5 s；SP 1.1 s；SP 混合负载 37 s MP 6.4 / 7.7 s；SP 4.3 s；SP 混合负载 4.5 s
换规格 FSx 换档 384 → 768：53.9 min，≤ 3.1 s 同左 升 9.7 s · 降 14.8 s 升 9.2–10.1 s · 降 5.4–9.9 s
扩容 / 缩容 0.1 / 0.3 s 0.1–0.2 s — 扩容 17 min，≤ 280 ms
在线版本升级 — 5.5.6 → 5.5.7：580 s，≤ 2.9 s，0 丢 — —
FSx 首选 AZ 网络分区 ≈ 80 s delivery 120 s：249 s；delivery 30 s：139 s / 永久卡死（≥ 770 s） 120–146 s（全集群）；delivery 30 s 时 2 / 4 卡死 不可比 不可比
非 FSx 首选 AZ 网络分区 25 s 22.7–30 s 不可比 不可比
FSx HA 主备切换 7 / 3 s ≤ 6.5 s（4 次） — —
FSx 备份 / IOPS / SSD 在线调整 — 0 s — —
broker ↔ FSx 网络切断 — 149 s，hard mount 无自动隔离 — —
S3 不可用 300 s 106 s 125–136 s（2 次）；900 s：534–737 s — —
混合：SP 24k + 事务 + 12 生产者 kill -9：21–24 s（另有背压停顿）；FSx 首选 AZ 分区：12 路全部 323 s、事务提交 > 60 s 无法完成；FSx HA 切换 ≈ 11 s + 45 min 内 13 次背压停顿 — 重启 1.2–2.8 s（无周期停顿）；配置滚动 37 s 重启 3.4–5.2 s、配置滚动 4.5 s（无周期停顿）

读法：AutoMQ 的计划内操作（扩缩、升级、FSx 运维）非常平滑；非计划故障里，凡是碰到 FSx 首选 AZ 或 S3，停写都在 100 s 以上，单分区比多分区更重（没有其他分区分担）。MSK 的停写全部来自计划内维护、全部自愈。

AutoMQ defects

AutoMQ 的关键问题（5.5.6 → 5.5.7）

编号 现象 5.5.6 5.5.7 影响
Q20 / Q21 kill -9 后自恢复启动失败 / broker 间转发通道卡死，部分分区 32–44 min 不可写、需人工重启 15 次中 3 次 16 次 0 次（MP 12 + SP 4） ✅ 大概率已修复（统计未到确证）
Q28 FSx 首选 AZ 分区后，幂等生产者因序号错乱（OUT_OF_ORDER）被持续拒写 MP 2 / 2 MP 2 / 4；SP 3 / 3 停写 ≥ 75 s，其中 2 次有生产者永久卡死（含双 FSx 1 次） ❌ 未修复；单分区下最重；delivery 120 s 只把「永久」缩成「隔离时长 + ≈ 120 s」
Q29 多生产者 ⇒ broker CPU ≈ 0.9 ⇒ 企业版背压把请求配额 20,000 → 2,388，produce 一并被限 — MP 2 / 2（5.4–8.6 s）；SP 24k 45 min 内 13 次 3–8 s ❌ 无故障也停写；与背压日志 ±1 s 对齐（§10.16、§10.18）
S3 回归 S3 不可用期间写路径停写 300 s：0 s 300 s：106–136 s（3 / 3）；900 s：534–737 s ❌ 回归；冷存储故障波及热路径
双 FSx 不自愈（新） 双 FSx 下失去一套 FSx ≈ 5 min，撤销后部分分区持续不可写 — 2 / 2 须人工重启；停写 333–573 s ❌ 厂商推荐的冗余方案引入新故障模式（§11.7）
Q30（新） 双 FSx 缩回单 FSx（2 → 1）后一台 broker 启动即崩溃循环，控制台任务无限挂起、不报错不回滚 — 1 / 1 ❌ 双 FSx 上线后不能安全回退；唯一出路是删实例重建（§11.4–§11.5）

另：FSx 首选 AZ 网络分区导致全集群停写 120–146 s，是「单 FSx HA pair 作 WAL」的架构特征，与版本、客户端参数无关（§10.5、§10.8）；FSx 邻居负载在 3,072 IOPS 时停写 9 s、6,144 IOPS 时 0 s ⇒ FSx 必须独占并留 IOPS 余量（§10.17）。

Throughput

吞吐上限与资源干扰

项 AutoMQ 5.5.7 MSK Standard MSK Express
单分区上限（200 B，调优后，r4） 200k ✅（p99 8.66 ms） 200k ✅（p99 5.84 ms） 200k ✅（p99 10.55 ms）
多分区可用写吞吐 FSx 384 档 ≈ 170–200 MiB/s（250 MiB/s 时 p99 154.5 ms） ≈ 63 MB/s 持续（3 × m7g.large right-sizing 推算；xlarge 未重测） 71.5 MB/s（3 × express.m7g.large × 23.8 MB/s 入向配额；xlarge 未重测）
历史回读 30 GB 期间写路径 max 257 ms（10 s > 100 ms） 47 ms（0 s） 243 ms（11 s > 100 ms）
资源边界 broker CPU（Q29 背压）、FSx IOPS / 吞吐档、网卡基线带宽 EBS 容量（写满 = 全集群不可用） 每 broker 入向配额
月成本（东京区价目，20k msg/s × 200 B，r4 规格） $2,930–3,084（含 FSx；开源版 $747） $1,575（kafka.m7g.xlarge） $2,782（express.m7g.xlarge）
Dual FSx

双 FSx：不能消除 FSx 单点

厂商建议「组合两个 FSx」。控制台 file_system_count = 2 部署 30.6 min，三台 broker 都同时挂载两套 FSx 的 WAL（测试记录 §10.23）。

验证 单 FSx 双 FSx 结论
稳态 p50 / p99（24 分区，1k → 50k msg/s） 6.5–7.5 / 9.9–15.9 ms 6.1–6.8 / 9.8–13.1 ms ✅ 略好（WAL 分摊到两套）
2 h 浸泡 p99.99 / max（24 分区，20k msg/s） 55.85 / 238.7 ms 26.55 / 56.8 ms ✅ 尾部明显更好
切断其中一套 FSx ≈ 66 s 全集群停写 62–70 s，0 失败 全集群停写 62–85 s，失败 1.7 万 ❌ 没有切换，反而更重
切断其中一套 FSx ≈ 300 s（单独 / 叠加 kill -9） （单 FSx broker↔FSx 切断 120 s：停写 149 s，自愈） 停写 333–573 s，失败 289 万 / 439 万；撤销后 10 min 仍不可写，须人工重启（2 / 2） ❌❌ 新的不自愈故障模式
计划内 HA 切换（单套 2 次 + 两套同时 2 次） 零确认 3–4 s，最大 ≤ 6.5 s 零确认 16–39 s（多段），最大 3.9–10.3 s，自愈 ⚠️ 更重
单分区切断其中一套 FSx ≈ 300 s — 单分区停写 369 s，90 万笔报失败（自愈） ❌ 对单分区无保护
FSx 首选 AZ（az2）网络分区 64 s （单 FSx，修复前 harness：126 s） 全集群停写 71–74 s，0 失败，自愈 ❌ 两套同时受影响
单分区 FSx 首选 AZ 分区 61 s + delivery 30 s（Q28） 1 次永久卡死、1 次 139 s 2 / 3 路生产者永久卡死（≥ 773 s），失败 786 万 ❌ 不缓解 Q28
单分区 FSx 首选 AZ 分区 61 s + delivery 120 s （修复前 harness、≈ 80 s：249 / 133 s） 72 s，0 失败，自愈 ⚠️ 更轻，但隔离条件不同、不能归因
两套 FSx 的首选节点 az2 两套都在 az2 ❌ 没有 AZ 分散

为什么：file_system_count = 2 是负载分摊（WAL 写入分布到两套 FSx 提升吞吐），不是健康感知的故障切换；每个 broker 同时依赖两套，NFS hard mount 下任意一套不可达，写到它上面的 WAL 就阻塞 ⇒ 故障面从 1 套变成 2 套。两套首选节点同在 az2，FSx 首选 AZ 分区时同时受影响。

结论：不建议为消除 FSx 单点而建双 FSx —— 它不但不切换，长时间失去一套时还会进入需要人工重启的状态；它的真实收益是稳态与长稳尾部更好（2 h p99.99 −52 %、max −76 %），可作为延迟 / 吞吐优化手段，但前提是接受更大的故障面，而且上线后不能安全回退到单 FSx（Q30：缩容后一台 broker 崩溃循环，只能删实例重建，§11.4–§11.5）。

Assessment

综合评估与部署建议

场景 推荐 前提
撮合订单总线（单分区、严格有序、多网关） MSK Standard（延迟最低、长稳尾部最好）或 MSK Express（高负载下维护停写最短最稳） 维护窗口避开交易时段（Standard 混合负载配置滚动实测 37 s）；网关按订单 ID 幂等重试（「报失败但已写入」> 0 是常态）；Standard 配 EBS 容量告警；Express 高字节率攒批；客户端 batch.size 256 KiB + zstd（level 1）、in-flight 1 · linger 0：调优后单分区 Standard / Express 实测都到 200k msg/s × 200 B（p99 5.84 / 10.55 ms，r4，m7g.xlarge 级）；默认 16 KiB 批、不压缩时 Standard 只确认 32,120/s、Express 85,698/s
撮合输出日志 / 成交回报（多分区、可容忍秒级） 三者均可；MSK 自愈性最好 AutoMQ 须排除订单 topic 的自动均衡、钉位、FSx 独占、按 CPU 留余量
行情 / 风控大数据流（多分区、高吞吐、历史回读） AutoMQ 或 MSK Express 回读与订单写路径物理隔离（独立集群或限速读者）

若必须使用 AutoMQ：客户端关幂等 + in-flight 1 + delivery 120 s（实测可避免 Q28 的永久卡死，但 ≈ 135 s 停写不变，§10.21；注意 r4 调优（batch 256 KiB + zstd）用的是 in-flight 5，in-flight 1 下的单分区吞吐上限未测 —— 须按业务在「规避 Q28」与「吞吐」之间取舍）、网关按订单 ID 去重、订单 topic 排除自动均衡并钉位、FSx 独占且留 IOPS 余量、broker 按 CPU 留余量（Q29 无客户端规避，linger 5 实测无效，§10.22）。

AutoMQ 要进入「有条件适合」，至少需要：修复 Q28（序号错乱后自动恢复）、背压豁免 produce（或给出阈值与开关）、修复 S3 回归；以及消除 FSx 单点的真正方案 —— 实测双 FSx 不能（§11.7），需要厂商给出健康感知的 WAL 切换。

Open items

待厂商确认与未覆盖

在 AWS 上运行 Apache Kafka

Amazon MSK：上游 Apache Kafka、RF3 跨 3 AZ、broker 间复制不收费。

了解 Amazon MSK
口径说明：「测试记录 §」为本次撮合场景实测记录的节号；实测 标记的数字来自同一实验室此前的 MSK 基准 run；S / C-S / M / E 为公开来源编号，见页脚。