突发 30 倍流量下 Kafka→批量写 MySQL 的背压与吞吐权衡：瓶颈该压在哪一层

背景

我负责一条订单事件分发链路：Kafka 3.6（3 broker，topic order-event 64 分区，峰值 12000 msg/s，日均约 3000 万条），消费组 16 实例（每实例 4 分区），下游是 MySQL 8.0（8C32G 单主 + 2 只读从，InnoDB，binlog 开，单实例写入 P50 约 8ms / P99 约 45ms）。

业务方有一个硬性约束：大促 / 秒杀场景下流量会瞬时冲到日常的 20~30 倍（也就是峰值 25 万~36 万 msg/s），且消费端不允许丢消息、不允许乱序（同一 order_id 必须保序）。

现象

• 稳态下（12k msg/s）我把 batch size 调到 500、worker 并发 4 时吞吐最高，P99 稳定在 60ms 以内；
• 一旦流量冲到 10 万 msg/s，MySQL 主库 CPU 立刻打满、binlog 写 IO 排队，P99 从 60ms 飙到 800ms+，消费端 lag 在 5 分钟内从 0 涨到 200 万；
• 我把 batch size 拉到 2000、并发拉到 16，吞吐确实上去了一些，但MySQL 侧 P99 进一步恶化到 3s+，且出现主从延迟 80s+，从库读流量被拖垮。

已尝试的排查

1. 调大 batch size + 并发 → 吞吐涨但 P99 和主从延迟都恶化，说明瓶颈在 MySQL 单主写入侧，不在消费端；
2. 把部分只读流量切到从库 → 从库被打挂，回滚；
3. 在消费端加本地队列缓冲（内存 queue 容量 10 万）→ 内存占用爆炸，GC 压力剧增，OOM 风险高；
4. 在消费端做 pause() 限流 → 见站内已有讨论（465 号帖），但 resume() 瞬间涌入积压打爆下游的问题还没解决。

我卡住的点

• 瓶颈该压在哪一层：是消费端限流（pause/resume 或本地队列）、还是批量写侧（更大 batch + 更少并发）、还是下游侧（拆库 / 队列化 / 异步落盘）？
• 背压如何精确传导到 Kafka：让 broker 端持有积压（磁盘可靠），而不是消费端内存爆炸——但如何避免 resume 瞬间涌入？
• 保序约束下，batch size 与并发度的联合最优解：同一 order_id 必须落在同一 worker，但 worker 数又影响并发度，这个 trade-off 有没有量化方法？

期望得到的答案形态

1. 一个可复现的压测方案：如何在 10 万~30 万 msg/s 下精确测量「消费端吞吐 / P99 / lag / 主从延迟」四个指标，并给出瓶颈定位的判据；
2. 背压传导的具体机制：Kafka 消费端如何用 pause() + max.poll.records + fetch.min.bytes 组合实现「慢消费」而非「快消费慢处理」，resume 瞬间涌入如何避免；
3. batch size 与 worker 并发的联合调参方法：在保序约束下，如何找到「单 worker 最大吞吐」与「总吞吐」的平衡点，有没有经验公式或压测脚本；
4. 下游 MySQL 侧的取舍：是拆库（按 order_id hash）、还是队列化（写前落 Kafka 再异步批量写）、还是异步落盘（binlog 组提交 + 大事务），各自的 P99 和一致性代价是什么。

我倾向「瓶颈压在下游 + 背压传导到 broker」，但缺一个可复现的量化方案来验证。期待社区里有类似场景的同学分享具体数字和取舍。