AWS 东京区同场实测 · 2026-10-28 → 11-07

撮合订单总线：四方对比
MSK Standard · MSK Express · AutoMQ 商业版 · AutoMQ 开源版

第一屏就是结论：每家最要命的问题、问题的性质、该怎么选。往下是条件、架构、计分卡和逐项证据（图表与原始数据）。

一页结论：每家的问题在哪、怎么选

测了什么：AWS 东京区，四家同为 m7g.xlarge 级 × 3 AZ；撮合订单流（单分区 · 200 B · acks=all + 幂等 · 逐条审计丢失 / 乱序 / 重复）；1k–200k msg/s 速率阶梯 + 1 h 浸泡（客户端由同一判据从 38 个调优组合中选出）；9 类故障（进程崩溃、受控重启、配置滚动、扩缩、存储 HA 切换、AZ 网络分区、AZ 级组合故障（AWS FIS：断网 + broker 下线）、S3 不可用、失去一套 FSx）。所有数字为实测，详细条件见下一节。

MSK Standard有条件适合
  • 客户端陷阱默认客户端参数卡住单分区batch 16 KiB 时只确认 32,120/s；调成 batch.size 256 KiB · zstd（level 1） 后 200k、p99 5.84 ms
  • 运维约束配置变更 = 滚动重启，高负载下停写放大单分区混合负载最坏一秒 37.4 s（单流 1.1 s）—— 交易时段不能改配置
  • 运维约束EBS 写满 = 整集群不可用实测事故：数据盘 90 % ⇒ 120 个分区离线 ≈ 2 h，扩盘 + 重启才恢复
  • 架构限制AZ 网络故障：自愈要 1–2 分钟，半数还有二次停写；运维迁 leader 可压到约 10 sFIS 近似 AZ 故障：最坏一秒 59.9 s–120 s；8 次中 4 次 broker 回来后 leader 被交还给仍断网的它。客户端 request 5 s + delivery 120 s 可把报失败降到 0（delivery 30 s 时每路 7.5–21 万笔），但缩短不了停写；服务端 leader.imbalance=100 实测无效。⇒ 运维 +10 s 主动迁 leader（reassign + preferred 选举，命令 9.4 s–9.8 s）⇒ 最坏一秒降到 7.4 s–11.8 s，2 次失败 + 丢失合计 0
  • 强项延迟与长稳最好，受控重启自愈1k p99 4.58 ms；1 h 浸泡 max 27.05 ms；重启停写 ≤ 2.2 s
月成本 $1,575 · 单分区上限 200k
MSK Express有条件适合
  • 客户端陷阱默认客户端参数同样卡住单分区16 KiB 批时 100k 只确认 85,698/s；调优后 200k、p99 10.55 ms
  • 架构限制尾延迟三家托管里最高1 h 浸泡 p99.99 48.95 ms、max 239 ms（Standard 15.35 ms / 27.05 ms）；历史回读时写入 max 243 ms
  • 架构限制配额是硬墙，没有突发额度超配额不报错只变慢；单 broker IAM 连接 3,100 个里只成功 2,544；TLS 1.3 不支持
  • 架构限制AZ 网络故障时部分消息被卡 1.5–2 minFIS 近似 AZ 故障：最坏一秒 89.9 s–118 s，期间仍有确认（不是全停）；另：负载下缩容被拒
  • 强项维护停写最短最稳配置滚动最坏一秒 ≤ 7.7 s，不随负载放大；不用管盘
月成本 $2,782 · 单分区上限 200k
AutoMQ 商业版（FSx WAL）不适合
  • 产品缺陷Q28：短暂网络分区后，生产者永久写不进去FSx 首选 AZ 分区 ≈ 60–80 s ⇒ 3 次里 1 次生产者再也没恢复（broker 一直回 OUT_OF_ORDER）；只能重建生产者
  • 产品缺陷Q30：双 FSx 回不到单 FSx缩容后 broker 崩溃 1,266 次、控制台挂起不报错；唯一出路删实例重建（40 min，数据丢弃）
  • 产品缺陷5.5.7 回归：S3 不可用就停写S3 不可用 300 s ⇒ 停写 106 s–120 s（5.5.6 为 0 s）
  • 产品缺陷Q29：不出故障也停写12 个生产者、无任何故障：CPU 背压把请求配额 20,000 → 2,388，produce 一起被限，最长确认 8.6 s；无开关
  • 架构限制FSx 是全集群唯一的 WAL 单点FIS 拿掉 FSx 首选节点所在的 AZ ⇒ 三个 AZ 的生产者全停，最坏一秒 300 s（其他 AZ：72.4 s）；双 FSx 是负载分摊不是切换，失去一套 ≈ 5 min 停写 300 s–1,176 s 且须人工重启
月成本 $2,930–$3,084 · 单分区上限 200k
AutoMQ 开源版（S3 WAL）不适合
  • 架构限制延迟下限由 S3 WAL 决定1k 时 p99 478 ms；调参只抬吞吐（到 100k），p50 始终 ≈ 360 ms
  • 运维约束高可用数据不足故障数据只有早一轮，未做逐条审计、浸泡与 AZ 分区
月成本 $747 · 单分区上限 100k

产品缺陷 厂商要修；客户端 / 配置绕不开 · 架构限制 方案本身如此，换配置也不变 · 运维约束 能管住，但要有人管 · 客户端陷阱 默认参数不行，必须调

AutoMQ 商业版的问题，是方案问题还是产品 bug？ 两者都有：产品缺陷 4 项（Q28、Q30、S3 回归、Q29 —— 要等厂商修，客户端 / 配置绕不开）；架构限制 1 项（WAL 只有一套 FSx HA pair —— 方案本身如此，双 FSx 也消除不了）。稳态性能不是问题：调优后单分区 200k、p99 8.66 ms。

怎么选

场景选必须做到
撮合订单总线（单分区、严格有序、不能停写）MSK Standard客户端 batch.size 256 KiB · zstd（level 1），并设 request.timeout 5 s · delivery.timeout 120 s（AZ 网络故障时 0 报失败）；配置变更放在休市窗口；EBS 容量告警；预案写明「AZ 网络故障 ≈ 1 min 停写、可能二次停写 ⇒ 10 s 内由运维迁 leader（实测迁后最坏一秒 7.4 s–11.8 s）」
同上，但更在意维护停写、不想管盘MSK Express同样调客户端；接受更高的尾延迟与配额硬墙；短连接网关用连接池
能容忍分钟级停写的多分区管道MSK 两家；AutoMQ 商业版须评估AutoMQ：订单 topic 排除自动均衡并钉位、FSx 独占留 IOPS、不上双 FSx
不在意延迟的批量 / 日志AutoMQ 开源版接受 ≈ 360 ms 的写确认

测试条件

先把条件钉死：只有条件相同的格子才并排比较。下面是环境、AZ 布局、负载与方法，以及哪些格子不能比。

环境

项MSK StandardMSK ExpressAutoMQ 商业版（FSx WAL）AutoMQ 开源版（S3 WAL）
版本Kafka 4.1.x（KRaft）Kafka 4.2.x（KRaft）BYOC 控制台 8.4.8 · 数据面 5.5.7（对照 5.5.6）1.7.4（基于 Kafka 3.9.1）
broker（性能测试）3 × kafka.m7g.xlarge（4 vCPU），每 AZ 1 台3 × express.m7g.xlarge（4 vCPU），每 AZ 1 台3 × m7g.xlarge（4 vCPU），每 AZ 1 台3 × m7g.xlarge（4 vCPU），每 AZ 1 台，controller + broker 合一
持久化EBS 400 GiB × 3；RF 3 · min.insync 2托管存储；3 副本单套 FSx for ONTAP（MULTI_AZ_2，1 个 HA pair：首选 az2 / 备用 az1），384 MBps，SSD 1,024–1,536 GiB；冷数据 S3；broker 单副本。双 FSx 只用于「双 FSx」专项（11-06 起）S3（WAL 与数据）；broker 单副本
客户端c7g.2xlarge × 3，每 AZ 1 台同左（同一组客户端）c7g.2xlarge × 3，每 AZ 1 台（独立 VPC）c7g.2xlarge × 1，apne1-az1（独立 VPC，与 broker 同 AZ 布局）
客户端参数（按同一规则选出的各自最优）batch.size 256 KiB · zstd（level 1） · in-flight 1 · linger 0batch.size 256 KiB · zstd（level 1） · in-flight 1 · linger 0batch.size 256 KiB · zstd（level 1） · in-flight 5 · linger 1 · 关 zone router · delivery 120 sbatch.size 512 KiB · linger 5 · zstd（level 1） · in-flight 5
性能测试2026-11-07（r4 同一轮）2026-11-07（r4 同一轮）2026-11-07（r4 同一轮，重建后的单 FSx 实例）2026-11-07（r4 同一轮）
故障测试11-02 → 11-07 · kafka.m7g.large · 默认客户端；受控重启 / FIS 11-08 · xlarge11-01 → 11-07 · express.m7g.large · 默认客户端；受控重启 / FIS 11-08 · xlarge11-02 → 11-08 · 5.5.7 · 推荐客户端10-28 → 10-29（早一轮）

AZ 布局：每样东西在哪个 AZ

三个 AZ 各一台 broker、一台客户端；单分区 topic 的 leader 一律在 apne1-az1。AutoMQ 商业版的 WAL 只落在 FSx 的两个节点上（首选 az2、备用 az1），az1 / az4 的 broker 每写一条都要跨 AZ —— 这决定了它的延迟底线，也决定了它对 az2 网络分区最敏感。

apne1-az1apne1-az2apne1-az4Standardbroker · kafka.m7g.xlargeEBS 400 GiB · RF 3 副本之一broker · kafka.m7g.xlargeEBS 400 GiB · RF 3 副本之一broker · kafka.m7g.xlargeEBS 400 GiB · RF 3 副本之一★ 单分区 leaderExpressbroker · express.m7g.xlarge托管存储 · 3 副本broker · express.m7g.xlarge托管存储 · 3 副本broker · express.m7g.xlarge托管存储 · 3 副本★ 单分区 leaderAutoMQ 商业版broker · m7g.xlarge单副本；WAL 走 NFS 写 FSxbroker · m7g.xlarge单副本；WAL 走 NFS 写 FSxbroker · m7g.xlarge单副本；WAL 走 NFS 写 FSx★ 单分区 leaderAutoMQ 开源版节点 · m7g.xlargecontroller + broker；WAL = S3节点 · m7g.xlargecontroller + broker；WAL = S3节点 · m7g.xlargecontroller + broker；WAL = S3★ 单分区 leaderFSx for ONTAP MULTI_AZ_2 × 1 套（AutoMQ 商业版的 WAL；主体数据均为单套）备用节点首选节点（正常时所有 WAL 写这里）没有 FSx 节点跨 AZ 写 WALS3（区域级）：AutoMQ 商业版的冷数据 · 开源版的 WAL 与数据（经 Gateway Endpoint）客户端 · c7g.2xlarge每 AZ 一台；单分区负载测试用 az1客户端 · c7g.2xlarge每 AZ 一台；单分区负载测试用 az1客户端 · c7g.2xlarge每 AZ 一台；单分区负载测试用 az1

负载与测量方法

Region / AZAWS 东京区 ap-northeast-1；AZ ID apne1-az1 / apne1-az2 / apne1-az4
写入语义acks=all + 幂等；开环定速（按计划时刻发送）；延迟从计划发送时刻算起；丢弃预热 10 s
单分区（业务场景）1 个分区，leader 钉在 apne1-az1；负载测试的生产者在 az1；故障测试三路生产者分在 az1 / az2 / az4
多分区（大数据场景）24 分区，每台 broker 各 8 个 leader
消息与 key200 B 订单 JSON（1,024 条互不相同，压缩比真实）+ 28 B 审计头；另有 4 KiB；64 个 key；同一个 Bench.java v8（kafka-clients 4.1.1）
速率阶梯1k / 5k / 10k / 20k / 50k / 100k / 200k msg/s，每档 120 s；四家同一轮（r4）
调优先按 MSK 圣经整理的 14 个参数扫 38 格（batch.size / zstd / in-flight / linger），再由代码按同一判据给每家选最优配置（不由人挑），最后用它跑阶梯与浸泡
浸泡20k msg/s × 200 B × 1 h，单生产者，最优配置
故障三路审计流各 5k msg/s × 200 B；t = 120 s 注入；NACL 规则并行生效，时长从生效时刻计
审计消费端逐条核对丢失 / 乱序 / 重复 / 「报失败但已写入」

不可比清单

四种架构：一条消息要走完哪几步才算写成功

同一种画法横排对照。数字越多的步骤、越远的落盘位置，延迟底线越高；标红的是单点。

MSK Standard1生产者 → leader broker（同 AZ或跨 AZ）2leader 写本地 EBS（pagecache）3并行复制到另外 2 个 AZ 的follower4min.insync = 2 满足 ⇒ 回 ackack 前必须完成的最慢一步一次跨 AZ 复制往返数据放在哪EBS × 3（每 AZ 一份）副本在 Kafka 层；broker 间复制不收费
MSK Express1生产者 → leader broker2服务内部持久化（3 副本，托管）3满足持久化 ⇒ 回 ackack 前必须完成的最慢一步托管存储写入数据放在哪托管存储（3 副本）存储与再平衡由服务管理
AutoMQ 商业版（FSx WAL）1生产者 → leader broker2NFS 同步写 FSx 首选节点（apne1-az2）3FSx 同步到备用节点（apne1-az1）4回 ack；之后后台把 WAL 上传 S3ack 前必须完成的最慢一步一次 NFS 同步写（az1 / az4 的 broker要跨 AZ）数据放在哪FSx（WAL）+ S3（数据）；broker 单副本单点FSx HA pair：只有 2 个节点、首选在 az2
AutoMQ 开源版（S3 WAL）1生产者 → leader broker2攒批后 PUT 到 S3（WAL）3S3 返回成功 ⇒ 回 ackack 前必须完成的最慢一步一次 S3 PUT（数十到数百 ms）数据放在哪S3（WAL 与数据）；broker 单副本没有本地盘；延迟由 S3 PUT 决定

这一步决定延迟的底线：单分区 1k msg/s 实测 p50 —— Standard 3.29 ms · Express 4.21 ms · AutoMQ 商业版 6.71 ms · AutoMQ 开源版 352 ms。

计分卡：12 条判据

在上面的条件与架构下得出；判定只针对撮合订单总线（低延迟、严格有序、不能停写）；每格是实测值，「—」不计分。

判据（门槛）MSK StandardMSK ExpressAutoMQ 商业版（FSx WAL）AutoMQ 开源版（S3 WAL）
延迟单分区 p99（1k–20k msg/s）≤ 10 ms✓4.6–4.7 ms✓8.0–8.5 ms✓7.7–8.1 ms✕≈ 478 ms
1 h 浸泡 p99.99 / max（最优配置）≤ 50 / 200 ms✓15.3 / 27 ms!49.0 / 239 ms✓33.8 / 89 ms—未测
12 生产者同写，无故障不停写（多分区，调优后）无 > 1 s✓max 48.75 ms✓max 70.93 ms✕max 7,551 ms—未测
历史回读期间写入 max≤ 200 ms✓47.00 ms!243 ms!258 ms—未测
吞吐单分区可持续上限（最优配置）≥ 50k msg/s 且 p99 ≤ 20 ms✓200k · p99 5.84 ms✓200k · p99 10.55 ms✓200k · p99 8.66 ms!100k · p99 496 ms
高可用进程崩溃后自愈且 ≤ 30 s（以下高可用行测于 11-07 前）≤ 30 s—不可注入—不可注入!16.1 s–34.2 s，9 次全部自愈✓12.0 s（早一轮 1 次）
AZ 级组合故障（FIS 近似，非真实断电）自愈且 ≤ 30 s!59.9 s–120 s；1 / 2 次二次停写!89.9 s–118 s；期间仍有确认✕其他 AZ 69.5 s–72.4 s；FSx 首选 AZ 全集群 300 s—未测
受控维护（重启 / 配置滚动）≤ 10 s!重启 ≤ 2.2 s；配置滚动最高 37.4 s✓重启 ≤ 2.6 s；配置滚动 ≤ 7.7 s✓受控关闭 2.4 s；扩缩 ≤ 0.27 s✓3.4 s（早一轮）
WAL 存储所在 AZ 分区自愈且 ≤ 30 s—不可比—不可比✕210 s；1 / 3 次永久卡死—未测
依赖存储故障（S3 不可用）≤ 10 s✓不依赖✓不依赖✕106 s–120 s—未测
存储单点单一存储故障不致全停✓RF 3✓托管✕FSx；双 FSx 也不能消除✓S3 区域级
数据安全（已确认 0 丢 / 乱序 / 重复）0✓0 / 0 / 0✓0 / 0 / 0✓0 / 0 / 0—未做逐条审计
成本同规格月成本（推算）——$1,575—$2,782—$2,930–$3,084—$747
撮合订单总线有条件适合调优后单分区 200k · p99 5.84 ms；故障全部自愈；维护须避开交易时段有条件适合调优后单分区 200k · p99 10.55 ms；高负载下维护停写最短最稳不适合Q28 永久卡死、Q29 背压停写、S3 回归、Q30 FSx 缩容致 broker 永久下线；FSx 单点，双 FSx 也不能消除不适合S3 WAL 延迟下限：1k 时 p99 478 ms，参数调不动

✓ 合适 · ! 有条件 · ✕ 不合适 · — 不可测 / 未测 / 不计分。每格数字由登记表从原始结果算出。

成本

同规格月成本（东京区公开价目 × 测试规格 × 声明的负载）

堆叠条 = 各计费项；AutoMQ 商业版的许可是区间（厂商公开价目的低 / 高档）。

$0$500$1,000$1,500$2,000$2,500$3,000MSK StandardMSK Standard · broker 小时 $1,154/月broker 小时 $1,154MSK Standard · EBS 存储 $144/月MSK Standard · 客户端跨 AZ 流量 $276/月$1,575 / 月MSK ExpressMSK Express · broker 小时 $2,308/月broker 小时 $2,308MSK Express · 写入费 $156/月MSK Express · 存储 $41/月MSK Express · 客户端跨 AZ 流量 $276/月$2,782 / 月AutoMQ 商业版（FSx WAL）AutoMQ 商业版（FSx WAL） · EC2 $462/月EC2 $462AutoMQ 商业版（FSx WAL） · FSx 吞吐 384 MBps $1,209/月FSx 吞吐 384 MBps $1,209AutoMQ 商业版（FSx WAL） · FSx SSD 1 TiB $307/月AutoMQ 商业版（FSx WAL） · FSx 额外 IOPS $125/月AutoMQ 商业版（FSx WAL） · AutoMQ 许可（低档） $404/月AutoMQ 商业版（FSx WAL） · S3 $9/月AutoMQ 商业版（FSx WAL） · 客户端跨 AZ 流量 $276/月AutoMQ 商业版（FSx WAL） · WAL 跨 AZ 写 FSx $138/月$2,930–$3,084 / 月AutoMQ 开源版（S3 WAL）AutoMQ 开源版（S3 WAL） · EC2 $462/月EC2 $462AutoMQ 开源版（S3 WAL） · S3 存储 $9/月AutoMQ 开源版（S3 WAL） · 客户端跨 AZ 流量 $276/月$747 / 月
  • 从低到高：AutoMQ 开源版 < Standard < Express < AutoMQ 商业版。
  • AutoMQ 商业版的 FSx（吞吐 + SSD + 额外 IOPS）一项 $1,641/月，超过 MSK Standard 整套（$1,575）。
  • 开源版最便宜，但延迟高两个数量级（见延迟一节）。
  • 跨 AZ 流量四家都一样（$276/月）：本页的低延迟配置都让客户端直连 leader；AutoMQ 的零跨 AZ 路由（zone router）会把 p99 拉到 13.75 ms。
推算不是账单；改负载假设会改变排序
负载
20k msg/s × 200 B 持续 30 天 ≈ 10,368 GB 写入；读 1 份；保留 24 h（≈ 346 GB）
规格
与实测相同：3 broker（MSK 为 *.m7g.xlarge），MSK Standard 每台 EBS 400 GiB，FSx 384 MBps / 1 TiB SSD / 6,144 IOPS（免费 3,072，余量见 X6）
价目
AWS Price List API，ap-northeast-1，按需价，30 天 = 730 h
账单核对
Cost Explorer 2026-11-05 全天单套 FSx：吞吐 $42/天 vs 模型 $40/天；额外 IOPS $4/天
跨 AZ
3 AZ 均匀分布 ⇒ 2/3 客户端流量跨 AZ，每 GB 两端各 $0.01
未计
S3 请求费、FSx 备份、监控、支持费、RI / SP 折扣
数据表 · 月成本
产品项 1项 2项 3项 4项 5项 6项 7项 8合计 / 月
MSK Standardbroker 小时 $1,154EBS 存储 $144客户端跨 AZ 流量 $276$1,575
MSK Expressbroker 小时 $2,308写入费 $156存储 $41客户端跨 AZ 流量 $276$2,782
AutoMQ 商业版（FSx WAL）EC2 $462FSx 吞吐 384 MBps $1,209FSx SSD 1 TiB $307FSx 额外 IOPS $125AutoMQ 许可（低档） $404S3 $9客户端跨 AZ 流量 $276WAL 跨 AZ 写 FSx $138$2,930–$3,084
AutoMQ 开源版（S3 WAL）EC2 $462S3 存储 $9客户端跨 AZ 流量 $276$747

延迟

单分区：写入确认 p99 随写入速率（各自最优配置）

对数纵轴；虚线 = 10 ms 门槛；✕ = 该速率下生产者跟不上。每家的配置由同一判据从 38 个调优格中选出。

过载：生产者跟不上，积压持续增长（✕）2 ms510 ms2050100 ms1 s5 s1k5k10k20k50k100k200k写入速率（msg/s，200 B，单分区）MSK Standard · 1k · p99 4.58 msMSK Standard · 5k · p99 4.66 msMSK Standard · 10k · p99 4.71 msMSK Standard · 20k · p99 4.67 msMSK Standard · 50k · p99 4.82 msMSK Standard · 100k · p99 5.04 msMSK Standard · 200k · p99 5.84 msMSK Express · 1k · p99 7.96 msMSK Express · 5k · p99 8.26 msMSK Express · 10k · p99 8.38 msMSK Express · 20k · p99 8.51 msMSK Express · 50k · p99 9.07 msMSK Express · 100k · p99 9.81 msMSK Express · 200k · p99 10.55 msAutoMQ 商业版（FSx WAL） · 1k · p99 7.83 msAutoMQ 商业版（FSx WAL） · 5k · p99 7.84 msAutoMQ 商业版（FSx WAL） · 10k · p99 7.74 msAutoMQ 商业版（FSx WAL） · 20k · p99 8.07 msAutoMQ 商业版（FSx WAL） · 50k · p99 8.06 msAutoMQ 商业版（FSx WAL） · 100k · p99 9.10 msAutoMQ 商业版（FSx WAL） · 200k · p99 8.66 msAutoMQ 开源版（S3 WAL） · 200k：过载✕AutoMQ 开源版（S3 WAL） · 1k · p99 478 msAutoMQ 开源版（S3 WAL） · 5k · p99 482 msAutoMQ 开源版（S3 WAL） · 10k · p99 484 msAutoMQ 开源版（S3 WAL） · 20k · p99 484 msAutoMQ 开源版（S3 WAL） · 50k · p99 486 msAutoMQ 开源版（S3 WAL） · 100k · p99 496 msAutoMQ 开源版 496 msExpress 10.55 msAutoMQ 商业版 8.66 msStandard 5.84 ms1k 时最低：Standard p99 4.58 ms，中位 3.29 ms200k msg/s 仍达标：Standard、Express、AutoMQ 商业版开源版（S3 WAL）482 ms：调参只抬吞吐延迟停在 S3 WAL 提交间隔
  • MSK Standard
  • MSK Express
  • AutoMQ 商业版（FSx WAL）
  • AutoMQ 开源版（S3 WAL）
四家同一轮可比
测试
四家同一轮（r4，11-07），均为 m7g.xlarge 级别
分区
1 个，leader apne1-az1
生产者
1 个，apne1-az1
消息
200 B 订单 JSON · acks=all · 幂等
每档
120 s
配置
Standard：batch.size 256 KiB · zstd（level 1） · in-flight 1 · linger 0 ｜ Express：batch.size 256 KiB · zstd（level 1） · in-flight 1 · linger 0 ｜ AutoMQ 商业版：batch.size 256 KiB · zstd（level 1） · in-flight 5 · linger 1 · 关 zone router · delivery 120 s ｜ AutoMQ 开源版：batch.size 512 KiB · linger 5 · zstd（level 1） · in-flight 5
数据表 · 单分区延迟
速率MSK StandardMSK ExpressAutoMQ 商业版（FSx WAL）AutoMQ 开源版（S3 WAL）
1kp99 4.58 ms / p50 3.29 msp99 7.96 ms / p50 4.21 msp99 7.83 ms / p50 6.71 msp99 478 ms / p50 352 ms
5kp99 4.66 ms / p50 3.31 msp99 8.26 ms / p50 4.83 msp99 7.84 ms / p50 6.26 msp99 482 ms / p50 354 ms
10kp99 4.71 ms / p50 3.31 msp99 8.38 ms / p50 4.86 msp99 7.74 ms / p50 6.25 msp99 484 ms / p50 354 ms
20kp99 4.67 ms / p50 3.37 msp99 8.51 ms / p50 4.84 msp99 8.07 ms / p50 6.28 msp99 484 ms / p50 354 ms
50kp99 4.82 ms / p50 3.46 msp99 9.07 ms / p50 4.99 msp99 8.06 ms / p50 6.33 msp99 486 ms / p50 358 ms
100kp99 5.04 ms / p50 3.67 msp99 9.81 ms / p50 5.13 msp99 9.10 ms / p50 6.50 msp99 496 ms / p50 362 ms
200kp99 5.84 ms / p50 4.30 msp99 10.55 ms / p50 5.30 msp99 8.66 ms / p50 6.67 ms过载

多分区：写入确认 p99 随写入速率（各自最优配置）

24 分区订单 topic，单生产者，同一套调优配置；大数据场景的参考。

过载：生产者跟不上，积压持续增长（✕）2 ms510 ms2050100 ms1 s5 s1k5k10k20k50k100k200k写入速率（msg/s，200 B，24 分区，单生产者）MSK Standard · 1k · p99 7.71 msMSK Standard · 5k · p99 8.43 msMSK Standard · 10k · p99 8.87 msMSK Standard · 20k · p99 9.10 msMSK Standard · 50k · p99 9.55 msMSK Standard · 100k · p99 10.25 msMSK Standard · 200k · p99 10.35 msMSK Express · 1k · p99 8.05 msMSK Express · 5k · p99 9.72 msMSK Express · 10k · p99 11.35 msMSK Express · 20k · p99 12.95 msMSK Express · 50k · p99 12.95 msMSK Express · 100k · p99 15.25 msMSK Express · 200k · p99 15.45 msAutoMQ 商业版（FSx WAL） · 1k · p99 10.15 msAutoMQ 商业版（FSx WAL） · 5k · p99 12.35 msAutoMQ 商业版（FSx WAL） · 10k · p99 13.85 msAutoMQ 商业版（FSx WAL） · 20k · p99 13.75 msAutoMQ 商业版（FSx WAL） · 50k · p99 14.25 msAutoMQ 商业版（FSx WAL） · 100k · p99 15.75 msAutoMQ 商业版（FSx WAL） · 200k · p99 17.15 msAutoMQ 商业版 17.15 msExpress 15.45 msStandard 10.35 ms
  • MSK Standard
  • MSK Express
  • AutoMQ 商业版（FSx WAL）
三家同一轮可比
测试
11-08 补全轮，三家 m7g.xlarge 级
分区
me-orders 24 个，64 个 key
生产者
1 个，apne1-az1
配置
batch 256 KiB · zstd（level 1）
数据表 · 多分区延迟
速率MSK StandardMSK ExpressAutoMQ 商业版（FSx WAL）
1kp99 7.71 ms / p50 4.29 msp99 8.05 ms / p50 4.12 msp99 10.15 ms / p50 7.08 ms
5kp99 8.43 ms / p50 5.14 msp99 9.72 ms / p50 5.22 msp99 12.35 ms / p50 7.28 ms
10kp99 8.87 ms / p50 5.32 msp99 11.35 ms / p50 5.61 msp99 13.85 ms / p50 7.54 ms
20kp99 9.10 ms / p50 5.37 msp99 12.95 ms / p50 5.93 msp99 13.75 ms / p50 7.76 ms
50kp99 9.55 ms / p50 5.50 msp99 12.95 ms / p50 5.89 msp99 14.25 ms / p50 7.95 ms
100kp99 10.25 ms / p50 5.59 msp99 15.25 ms / p50 6.08 msp99 15.75 ms / p50 8.21 ms
200kp99 10.35 ms / p50 5.87 msp99 15.45 ms / p50 6.38 msp99 17.15 ms / p50 8.35 ms

单分区：1 小时浸泡的尾部（最优配置）

同一负载跑 1 小时，看 p50 → max 拉多长。

2 ms510 ms2050100 ms200400 msp99.99 门槛 50 msMSK StandardMSK Standard · p50 3.33 msp50MSK Standard · p99 4.63 msMSK Standard · p99.9 8.68 msMSK Standard · p99.99 15.35 msp99.99MSK Standard · max 27.05 msmaxmax 27.05 ms · 0 s > 100 msMSK ExpressMSK Express · p50 4.82 msp50MSK Express · p99 8.81 msMSK Express · p99.9 18.75 msMSK Express · p99.99 48.95 msp99.99MSK Express · max 239 msmaxmax 239 ms · 2 s > 100 msAutoMQ 商业版（FSx WAL）AutoMQ 商业版（FSx WAL） · p50 6.37 msp50AutoMQ 商业版（FSx WAL） · p99 7.89 msAutoMQ 商业版（FSx WAL） · p99.9 15.05 msAutoMQ 商业版（FSx WAL） · p99.99 33.75 msp99.99AutoMQ 商业版（FSx WAL） · max 88.82 msmaxmax 88.82 ms · 0 s > 100 msAutoMQ 开源版（S3 WAL）未做浸泡（S3 WAL 延迟下限 ≈ 360 ms，不作订单总线）
同一轮可比
负载
20k msg/s × 200 B × 1 h
分区
1 个，leader apne1-az1
生产者
1 个
配置
同上图
数据表 · 1 h 浸泡
产品p50p99p99.9p99.99max> 100 ms 秒数条数
MSK Standard3.33 ms4.63 ms8.68 ms15.35 ms27.05 ms072,000,000
MSK Express4.82 ms8.81 ms18.75 ms48.95 ms239 ms272,000,000
AutoMQ 商业版（FSx WAL）6.37 ms7.89 ms15.05 ms33.75 ms88.82 ms072,000,000

吞吐与干扰

调优前后：单分区上限差多少

浅色 = Bench 默认参数（batch.size 16 KiB、不压缩）；深色 = 最优配置。MSK 的单分区上限主要卡在客户端默认批大小，不在 broker。

1k5k10k20k50k100k200kMSK StandardMSK Standard 默认参数：20k默认参数：达标到 20k；更高档过载，最多确认 32,120/sMSK Standard 调优后：200k调优后 200k · batch.size 256 KiB · zstd（level 1） · in-flight 1 · linger 0MSK ExpressMSK Express 默认参数：50k默认参数：达标到 50k；更高档过载，最多确认 85,698/sMSK Express 调优后：200k调优后 200k · batch.size 256 KiB · zstd（level 1） · in-flight 1 · linger 0AutoMQ 商业版（FSx WAL）AutoMQ 商业版（FSx WAL） 默认参数：20k默认参数：达标到 20k；更高档过载，最多确认 62,780/sAutoMQ 商业版（FSx WAL） 调优后：200k调优后 200k · batch.size 256 KiB · zstd（level 1） · in-flight 5 · linger 1 · 关 zone router · delivery 120 sAutoMQ 开源版（S3 WAL）AutoMQ 开源版（S3 WAL） 默认参数：1k默认参数：达标到 1k；更高档过载，最多确认 1,460/sAutoMQ 开源版（S3 WAL） 调优后：100k调优后 100k · batch.size 512 KiB · linger 5 · zstd（level 1） · in-flight 5
四家同一轮可比
判据
吞吐达标 = 确认 ≥ 97% 目标速率、0 丢 0 失败、p99 ≤ 自身 1k 时 p99 的 2 倍；低延迟达标 = 吞吐达标且 p50 < 20 ms、无 > 100 ms 的秒。开源版用吞吐达标（S3 WAL 延迟下限）
定义
tools/h2h/r4_table.py（唯一定义；选配置也用它）
其余
同延迟图
数据表 · 关键格复现 3 次
产品单元第 1 次第 2 次第 3 次判定
MSK Standardsp-r10k（调优）! p99 4.71 ms✓ p99 4.58 ms✓ p99 4.63 ms不一致 ⇒ 临界点
MSK Standardsp-r200k（调优）✓ p99 5.84 ms✓ p99 5.79 ms✓ p99 5.96 ms一致
MSK Expresssp-r50k（调优）! p99 9.07 ms✓ p99 9.34 ms✓ p99 9.40 ms不一致 ⇒ 临界点
MSK Expresssp-r200k（调优）✓ p99 10.55 ms✓ p99 11.05 ms✓ p99 10.75 ms一致
AutoMQ 商业版（FSx WAL）sp-r50k（默认批）✕ 过载✕ 过载✓ p99 13.05 ms不一致 ⇒ 临界点
AutoMQ 商业版（FSx WAL）sp-r200k（调优）✓ p99 8.66 ms✓ p99 9.04 ms✓ p99 9.76 ms一致
数据表 · 调优前后
产品默认参数达标到更高档过载时最多确认最优配置达标到最优配置
MSK Standard20k32,120/s200kbatch.size 256 KiB · zstd（level 1） · in-flight 1 · linger 0
MSK Express50k85,698/s200kbatch.size 256 KiB · zstd（level 1） · in-flight 1 · linger 0
AutoMQ 商业版（FSx WAL）20k62,780/s200kbatch.size 256 KiB · zstd（level 1） · in-flight 5 · linger 1 · 关 zone router · delivery 120 s
AutoMQ 开源版（S3 WAL）1k1,460/s100kbatch.size 512 KiB · linger 5 · zstd（level 1） · in-flight 5

单分区可持续上限（最优配置）

对数横轴；撮合场景的瓶颈是单分区（同一 symbol 不能拆分区）。

1k5k10k20k50k100k200kMSK StandardMSK Standard：200k msg/s200k msg/s · p99 5.84 msMSK ExpressMSK Express：200k msg/s200k msg/s · p99 10.55 msAutoMQ 商业版（FSx WAL）AutoMQ 商业版（FSx WAL）：200k msg/s200k msg/s · p99 8.66 msAutoMQ 开源版（S3 WAL）AutoMQ 开源版（S3 WAL）：100k msg/s100k msg/s · p99 496 ms（达不到 20 ms 门槛）
四家同一轮可比
判据
同上；开源版用吞吐达标
其余
同延迟图
数据表 · 单分区上限
产品最高档该档 p99
MSK Standard200k5.84 ms
MSK Express200k10.55 ms
AutoMQ 商业版（FSx WAL）200k8.66 ms
AutoMQ 开源版（S3 WAL）100k496 ms

AutoMQ 商业版：规避 Q28 的吞吐代价（in-flight 5 vs 1）

Q28 的客户端规避需要 in-flight 1（加关幂等）；同一套批大小与压缩下，in-flight 1 的单分区阶梯。

过载：生产者跟不上，积压持续增长（✕）2 ms510 ms2050100 ms1 s5 s1k5k10k20k50k100k200k写入速率（msg/s，200 B，单分区，batch 256 KiB + zstd）AutoMQ 商业版 · in-flight 5（调优） · 1k · p99 7.83 msAutoMQ 商业版 · in-flight 5（调优） · 5k · p99 7.84 msAutoMQ 商业版 · in-flight 5（调优） · 10k · p99 7.74 msAutoMQ 商业版 · in-flight 5（调优） · 20k · p99 8.07 msAutoMQ 商业版 · in-flight 5（调优） · 50k · p99 8.06 msAutoMQ 商业版 · in-flight 5（调优） · 100k · p99 9.10 msAutoMQ 商业版 · in-flight 5（调优） · 200k · p99 8.66 msAutoMQ 商业版 · in-flight 1（Q28 规避） · 1k · p99 12.05 msAutoMQ 商业版 · in-flight 1（Q28 规避） · 5k · p99 11.95 msAutoMQ 商业版 · in-flight 1（Q28 规避） · 10k · p99 12.15 msAutoMQ 商业版 · in-flight 1（Q28 规避） · 20k · p99 12.25 msAutoMQ 商业版 · in-flight 1（Q28 规避） · 50k · p99 12.45 msAutoMQ 商业版 · in-flight 1（Q28 规避） · 100k · p99 13.25 msAutoMQ 商业版 · in-flight 1（Q28 规避） · 200k · p99 13.75 msin-flight 1 13.75 msin-flight 5 8.66 ms
  • AutoMQ 商业版（FSx WAL）
同一实例同一轮
配置
batch 256 KiB · zstd（level 1）· linger 1 · 关 zone router · delivery 120 s
对照
实线 in-flight 5（调优），虚线 in-flight 1
注意
本格未关幂等（审计需要），只量化 in-flight 1 的吞吐代价
数据表 · in-flight 对比
速率in-flight 5in-flight 1
1kp99 7.83 msp99 12.05 ms
5kp99 7.84 msp99 11.95 ms
10kp99 7.74 msp99 12.15 ms
20kp99 8.07 msp99 12.25 ms
50kp99 8.06 msp99 12.45 ms
100kp99 9.10 msp99 13.25 ms
200kp99 8.66 msp99 13.75 ms

历史回读对写路径的干扰

两个读者从最早位置回读 30 GB 冷数据，同时 5k msg/s 写订单。

0 ms50 ms100 ms200 ms300 msMSK Standard回读期间写入 max 47.00 msMSK Express回读期间写入 max 243 msAutoMQ 商业版（FSx WAL）回读期间写入 max 258 ms
同方法可比
回读
2 个消费者 × 全速 × 30 GB
写入
5k msg/s × 200 B，审计
开源版
未测

高可用

每类故障的停写时长

对数横轴；一行一类故障，每个产品一个点或一段范围（多次 run 的最小–最大）；▶ 表示到测试结束仍未恢复。

0.1 s1 s10 s1 min5 min20 min10 s30 s▶ 永久 = 到测试结束仍未恢复进程崩溃：kill -9 leader 所在节点AutoMQ 商业版（FSx WAL） · 进程崩溃：kill -9 leader 所在节点：16.1 s–34.2 s（9 次）AutoMQ 商业版（FSx WAL） · 进程崩溃：kill -9 leader 所在节点：16.1 s–34.2 s（9 次）AutoMQ 商业版 16.1 s–34.2 sAutoMQ 开源版（S3 WAL） · 进程崩溃：kill -9 leader 所在节点：12.0 s（1 次）AutoMQ 开源版 12.0 s（早一轮）受控重启 leader 所在节点MSK Standard · 受控重启 leader 所在节点：1.1 s–2.2 s（2 次）MSK Standard · 受控重启 leader 所在节点：1.1 s–2.2 s（2 次）Standard 1.1 s–2.2 sMSK Express · 受控重启 leader 所在节点：2.3 s–2.6 s（2 次）MSK Express · 受控重启 leader 所在节点：2.3 s–2.6 s（2 次）Express 2.3 s–2.6 sAutoMQ 商业版（FSx WAL） · 受控重启 leader 所在节点：2.4 s（1 次）AutoMQ 商业版 2.4 sAutoMQ 开源版（S3 WAL） · 受控重启 leader 所在节点：3.4 s（1 次）AutoMQ 开源版 3.4 s（早一轮）配置滚动（单分区 24k msg/s + 12 生产者 + 事务）MSK Standard · 配置滚动（单分区 24k msg/s + 12 生产者 + 事务）：37.4 s（1 次）Standard 37.4 sMSK Express · 配置滚动（单分区 24k msg/s + 12 生产者 + 事务）：4.5 s（1 次）Express 4.5 s在线扩缩MSK Express · 在线扩缩：0.28 s（1 次）Express 0.28 sAutoMQ 商业版（FSx WAL） · 在线扩缩：0.07 s–0.27 s（4 次）AutoMQ 商业版（FSx WAL） · 在线扩缩：0.07 s–0.27 s（4 次）AutoMQ 商业版 0.07 s–0.27 sAutoMQ 开源版（S3 WAL） · 在线扩缩：2.4 s（1 次）AutoMQ 开源版 2.4 s（早一轮）存储 HA 主备切换（FSx）AutoMQ 商业版（FSx WAL） · 存储 HA 主备切换（FSx）：4.0 s–7.6 s（4 次）AutoMQ 商业版（FSx WAL） · 存储 HA 主备切换（FSx）：4.0 s–7.6 s（4 次）AutoMQ 商业版 4.0 s–7.6 sAZ 级组合故障（FIS）MSK Standard · AZ 级组合故障（FIS）：59.9 s–120 s（2 次）MSK Standard · AZ 级组合故障（FIS）：59.9 s–120 s（2 次）Standard 59.9 s–120 sMSK Express · AZ 级组合故障（FIS）：89.9 s–118 s（2 次）MSK Express · AZ 级组合故障（FIS）：89.9 s–118 s（2 次）Express 89.9 s–118 sAutoMQ 商业版（FSx WAL） · AZ 级组合故障（FIS）：69.5 s–72.4 s（2 次）AutoMQ 商业版（FSx WAL） · AZ 级组合故障（FIS）：69.5 s–72.4 s（2 次）AutoMQ 商业版 69.5 s–72.4 sAZ 级组合故障：FSx 首选 AZAutoMQ 商业版（FSx WAL） · AZ 级组合故障：FSx 首选 AZ：300 s（2 次）AutoMQ 商业版（FSx WAL） · AZ 级组合故障：FSx 首选 AZ：300 s（2 次）AutoMQ 商业版 300 sAZ 网络故障 + 运维主动迁 leader（E4）MSK Standard · AZ 网络故障 + 运维主动迁 leader（E4）：7.4 s–11.8 s（2 次）MSK Standard · AZ 网络故障 + 运维主动迁 leader（E4）：7.4 s–11.8 s（2 次）Standard 7.4 s–11.8 sWAL 存储所在 AZ 网络分区（FSx 首选 AZ）AutoMQ 商业版（FSx WAL） · WAL 存储所在 AZ 网络分区（FSx 首选 AZ）：30.3 s–210 s（3 次）AutoMQ 商业版（FSx WAL） · WAL 存储所在 AZ 网络分区（FSx 首选 AZ）：30.3 s–210 s（3 次）▶AutoMQ 商业版 30.3 s–210 s · 1 / 3 次永久卡死对象存储 S3 不可用 300 sAutoMQ 商业版（FSx WAL） · 对象存储 S3 不可用 300 s：106 s–120 s（3 次）AutoMQ 商业版（FSx WAL） · 对象存储 S3 不可用 300 s：106 s–120 s（3 次）AutoMQ 商业版 106 s–120 s双 FSx：失去其中一套 ≈ 5 minAutoMQ 商业版（FSx WAL） · 双 FSx：失去其中一套 ≈ 5 min：300 s–1,176 s（3 次）AutoMQ 商业版（FSx WAL） · 双 FSx：失去其中一套 ≈ 5 min：300 s–1,176 s（3 次）AutoMQ 商业版 300 s–1,176 s · 须人工重启
  • MSK Standard
  • MSK Express
  • AutoMQ 商业版（FSx WAL）
  • AutoMQ 开源版（S3 WAL）
同类故障可比受控重启与 AZ 级组合故障为 11-08 xlarge，其余测于 11-07 前（MSK *.m7g.large · 默认客户端）；MSK 不能注入进程崩溃；FIS 不是真实 AZ 断电
指标
最坏一秒确认延迟（≈ 停写时长）
负载
三路审计流 × 5k msg/s × 200 B（开源版 2k × 512 B）
单分区
leader apne1-az1；生产者分在 az1 / az2 / az4
数据表 · 故障停写
故障MSK StandardMSK ExpressAutoMQ 商业版（FSx WAL）AutoMQ 开源版（S3 WAL）
进程崩溃：kill -9 leader 所在节点托管服务不能注入托管服务不能注入16.1 s–34.2 s（9 次）12.0 s（1 次）
受控重启 leader 所在节点1.1 s–2.2 s（2 次）2.3 s–2.6 s（2 次）2.4 s（1 次）3.4 s（1 次）
配置滚动（单分区 24k msg/s + 12 生产者 + 事务）37.4 s（1 次）4.5 s（1 次）未单独测未测
在线扩缩未测0.28 s（1 次）0.07 s–0.27 s（4 次）2.4 s（1 次）
存储 HA 主备切换（FSx）无此组件服务托管4.0 s–7.6 s（4 次）无此组件
AZ 级组合故障（FIS）59.9 s–120 s（2 次）89.9 s–118 s（2 次）69.5 s–72.4 s（2 次）未测
AZ 级组合故障：FSx 首选 AZ无此单点无此单点300 s（2 次）未测
AZ 网络故障 + 运维主动迁 leader（E4）7.4 s–11.8 s（2 次）未测—（FSx 路径问题，迁 leader 无效）未测
WAL 存储所在 AZ 网络分区（FSx 首选 AZ）NACL 只断客户端路径，不可比同左30.3 s–210 s（3 次），有永久卡死未测
对象存储 S3 不可用 300 s不依赖 S3不依赖 S3106 s–120 s（3 次）S3 即 WAL，未测
双 FSx：失去其中一套 ≈ 5 min——300 s–1,176 s（3 次）—

故障时间线：每秒确认数（原始 run 数据）

前两张是 MSK 受控重启；中间两张是 AutoMQ 商业版 —— kill -9 能自愈，FSx 首选 AZ 分区后生产者再也没恢复；最后两张是 AWS FIS 的 AZ 级组合故障。

MSK Standard · 重启 leader 所在 broker
注入05k/s≥ 10k/s0+2 min+5 min+10 min

自愈 · 注入后零确认 0 秒 · 最坏一秒 0.70 s

MSK Express · 重启 leader 所在 broker
注入05k/s≥ 10k/s0+2 min+5 min+10 min

自愈 · 注入后零确认 0 秒 · 最坏一秒 1.8 s

AutoMQ 商业版 · kill -9 leader 所在 broker
注入05k/s≥ 10k/s0+2 min+5 min+10 min

自愈 · 注入后零确认 15 秒 · 最坏一秒 16.1 s

AutoMQ 商业版 · FSx 首选 AZ 网络分区（delivery 30 s）
注入05k/s≥ 10k/s0+2 min+5 min+10 min

到测试结束仍为 0 确认（永久卡死） · 注入后零确认 655 秒 · 此后再无确认

MSK Standard · FIS AZ 级组合故障（二次停写）
注入05k/s≥ 10k/s0+2 min+5 min+10 min

自愈 · 注入后零确认 177 秒 · 最坏一秒 120 s

AutoMQ 商业版 · FIS 拿掉 FSx 首选 AZ
注入05k/s≥ 10k/s0+2 min+5 min+10 min

自愈 · 注入后零确认 366 秒 · 最坏一秒 300 s

原始逐秒数据
纵轴
每秒确认条数（主流 5k/s，补写峰值截到 10k）
横轴
注入时刻 = 0
色带
故障持续区间

不出故障也停写：12 个生产者写同一分区

同负载、每秒最大确认延迟（对数纵轴）。

1 ms10 ms100 ms1 s10 s0 min5 min10 min15 min20 min25 min30 min35 min40 min45 min45 min 内 13 次 3–8 s：CPU 背压限流（Q29），与 broker 日志逐秒对齐请求配额 20,000 → 2,388 req/sMSK Standard 同负载（蓝）：只有重启那一秒 ≈ 1.5 s，其余 < 60 ms
  • MSK Standard
  • AutoMQ 商业版（FSx WAL）
同负载可比
负载
单分区 24k msg/s（3 × 5k + 9 × 1k）+ 1 路事务
AutoMQ
45 min，中途做了一次 FSx HA 切换
MSK
同负载 15 min，中途重启一次 broker

每家的不足：把机制画出来

结论很短，原因要讲清楚。以下每一条都来自实测，并画出了从起因到后果的链条。

展开：每个问题从起因到后果的机制图

AutoMQ 商业版（FSx WAL）

① Q28：一次短暂的 AZ 分区，让幂等生产者永久停写

生产者（幂等）leader broker（apne1-az1）FSx 首选节点（apne1-az2）批次 seq 100–104NFS 写 WAL✕ az2 网络分区：WAL 写阻塞（hard mount）delivery 30 s 到期：批次报失败，seq 继续向前新批次 seq 105…分区恢复：broker 认为序号不连续OUT_OF_ORDER_SEQUENCE ⇒ 拒绝重试同一序号 ⇒ 永远被拒

实测（单分区，FSx 首选 AZ 分区 ≈ 60–80 s）：3 次中 1 次生产者永久卡死；其余停写 30.3 s–210 s；双 FSx 下同一场景也永久卡死。关幂等 + in-flight 1 可避免永久卡死，但 ≈ 135 s 停写不变。

② Q29：不出故障也停写 —— CPU 背压限的是全部请求，包括 produce

12 个生产者写同一集群每台 broker ≈ 5.3kreq/s（m7g.xlarge）broker CPU ≈ 0.9企业版 CPUChecker 判 HIGH请求配额 20,000 → 2,388QuotaRegulator 下调RequestRate，produce 不豁免produce 排队超过 5 s客户端 request.timeout 到期、重发停写 3–8.6 s，每 ≈ 5min 一次单分区 24k msg/s 45 min 内13 次；linger 5 无效

③ FSx 是单点：只有两个节点，首选在 az2

WAL 只写 FSx 首选节点所有 broker 每条消息都要 NFS 同步写apne1-az2az2 网络分区 / NFS 切断NFS hard mount ⇒ 写阻塞，不报错全集群停写多分区 120–146 s；NFS 切断 120 s 停149 s不会自动隔离坏路径无健康检查切到备用节点

④ 双 FSx 不是故障切换，而是把故障面翻倍

broker 同时依赖 A、B 两套 FSxfile_system_count = 2 = 负载分摊A 不可达写到 A 的 WAL 阻塞全集群停写失去一套 ≈ 5 min 停写 300 s–1,176sA 恢复后仍有分区不可写10 min 不自愈，人工重启才恢复（2 /2）

⑤ 其他

  • S3 回归：S3 不可用 300 s ⇒ 停写 106 s–120 s（5.5.6 为 0 s）——冷存储故障波及热路径。
  • 历史回读干扰：两个读者回读 30 GB 时写入 max 258 ms。
  • 自动均衡：每 600 s 迁移 leader，单次停顿约 1–1.9 s；订单 topic 必须排除并钉位。
  • FSx 邻居负载：同一 FSx 上的其他负载会让 WAL 停写（3,072 IOPS 时 9 s），FSx 必须独占并留 IOPS 余量。
  • Q30：双 FSx 回不去单 FSx：缩容 2 → 1 后一台 broker 启动即致命退出（崩溃 1,266 次），控制台任务挂起不报错、API 无法回退；唯一出路是删实例重建（40 min，数据丢弃）。

AutoMQ 开源版（S3 WAL）

每批写进 S3 WAL 才回 ack没有本地盘、没有 FSxWAL 按固定间隔提交默认 16 KiB 批时上限只有 1,460msg/s调大批 + in-flight 5吞吐到 100k msg/s（batch.size 512KiB · linger 5 · zstd（level 1）· in-flight 5）延迟不随参数变各档 p50 352 ms–362 ms
  • 延迟 / 吞吐为 r4 同一轮；故障数据只有早一轮，未做逐条审计、浸泡与 AZ 分区。

MSK Standard

① 配置滚动的停写随负载放大

0 s10 s20 s30 s40 s单分区，单流最坏一秒 1.1 s多分区（2 次）最坏一秒 19.5 s（另一次 3.4 s）单分区混合负载（12 生产者 + 事务）最坏一秒 37.4 s

② 磁盘写满 = 整集群不可用

  • 数据盘 90 % ⇒ 120 个分区离线 ≈ 2 h，扩盘 + 重启才恢复（实测事故）：EBS 不会自动扩，必须配容量告警与保留策略。
  • 默认客户端参数是陷阱：batch.size 默认 16 KiB 时单分区只能确认 32,120 msg/s（每个请求只装一个 73 条的批）；改成 batch.size 256 KiB · zstd（level 1） · in-flight 1 · linger 0 后到 200k msg/s、p99 5.84 ms。in-flight 加到 5 不增吞吐、只加排队。
  • 维护窗口：RebootBroker / 配置变更都由 AWS 滚动执行，交易时段须避开。

MSK Express

  • 延迟分布：单分区 p99 7.96 ms–10.55 ms（达标各档）；1 h 浸泡 p99.99 48.95 ms、max 239 ms、2 秒超过 100 ms。
  • 单分区上限同样卡在默认批大小：默认 16 KiB 批时 100k msg/s 只确认 85,698/s；调大批 + zstd 后到 200k（batch.size 256 KiB · zstd（level 1） · in-flight 1 · linger 0）。不压缩、只调大批也能确认 ≈ 10 万 / s ⇒ 封顶的是每秒请求数，不是字节配额。
  • 历史回读拖慢写路径：回读期间写入 max 243 ms（Standard 47.00 ms）。
  • 运维约束：钉 leader 要先暂停 Intelligent Rebalancing；时间戳超出 ±24 h 的写入被拒；缩容要求新 broker 上没有用户分区；只开放部分 broker 配置项。

配置滚动：最坏一秒 4.2 s–7.7 s，不随负载放大

0 s10 s20 s30 s40 s单分区，单流最坏一秒 4.2 s多分区（2 次）最坏一秒 7.7 s（另一次 6.4 s）单分区混合负载（12 生产者 + 事务）最坏一秒 4.5 s

方法与经验

复测时最容易让判据「看着在工作、实际没有」的几处。

展开：测试方法与踩坑
  • 故障时长要实测，不能信名义值：串行创建 30 条 NACL + 30 个兜底定时任务会让「60 s 切断」实际变成 190 s、三个 AZ 先后生效；已改并行，时长从生效时刻计，并在结果里写实测「注入 → 撤销」秒数。
  • 「丢失」先拆开：大流量 + 长停顿后审计消费者会跟不上，尾部会被记成丢失；同分区其他审计流读到末尾 = 数据完整，只有中间缺口才是真丢。
  • 文件时间 ≠ 事件时间：压测的真实开始时刻在 .started 文件内容里，用文件 mtime 对齐日志会错开几分钟。
  • 放置漂移会让故障失真：隔离后 leader 不迁回，下一次 kill 那台 broker 等于杀一台空节点 —— 结果必须登记为无代表性。
  • 客户端规避要实测：linger 5 对 Q29 无效（每生产者 2k msg/s × 24 分区，5 ms 内每分区不到 1 条，攒不成批）；关幂等对 Q28 只消除「永久」，不缩短停写。