Kafka 分区级保序批量写 MySQL：batch size 与 worker 并发度的联合最优解怎么找

背景 我负责一条埋点事件流管道：Kafka 16 分区（单 broker 3C 部署），消费组 8 实例，每实例起 4 个 worker 线程，按 partition 分片（即每个 partition 固定绑 1 个 worker，分区内严格顺序）。worker 内部按「攒 batch → 批量 multi-row INSERT → 单事务 commit」写 MySQL 8.0.32（InnoDB，binlog_format=ROW，sync_binlog=1，innodb_flush_log_at_trx_commit=1，主从 16C64G，从库走读流量）。

现象

• 单实例 4 worker、batch=500 时：单机吞吐 ~1.8 万行/s，P50 38ms，P99 180ms，稳定。
• 扩到 8 实例后：总吞吐 ~13 万行/s（远不到 1.8×8=14.4 万的线性预期），P99 间歇飙到 900ms~1.3s，主从延迟在 1.5~4s 之间波动。
• 主库 top 指标：CPU 峰值 62%，iostat 显示 await 12ms，redo log 写入频率很高；从库 apply 队列堆积明显。
• 已排除：连接池（HikariCP maxSize=16，active 峰值 9）、网络（同机房 RTT <0.3ms）、慢 SQL（无锁等待超过 50ms 的记录）。

已尝试

1. 把 batch size 从 500 调到 2000：单机吞吐略涨到 2.1 万行/s，但 P99 恶化到 350ms，8 实例总吞吐没明显变化（~13.5 万行/s），主从延迟反而更长。
2. 把 worker 数从 4 降到 2（每实例只消费 2 个分区）：吞吐掉到 7.5 万行/s，主从延迟降到 1s 以下，P99 回到 200ms 左右——说明并发写是延迟的主因之一。
3. 尝试把 sync_binlog 临时改成 1000：吞吐涨 15%，P99 改善，但 DBA 不接受这个风险。

核心疑问 在「分区级保序」这个硬约束下（不能让同一 partition 的消息被两个 worker 并行处理），batch size 和每实例 worker 数这两个旋钮的联合最优解大概在哪个区域？ 具体想问：

1. 扩展性瓶颈到底主要卡在 InnoDB redo 刷盘、行锁竞争、还是主从复制带宽？有没有可复现的压测方法帮我定量拆解这三者的占比？
2. 如果 batch size 从 500→2000 的边际收益只有 17% 且 P99 恶化，是不是说明当前瓶颈已经不在「单批写」而在「commit 频率 × 主从 apply 速率」？那 batch size 还有继续加的空间吗？
3. 有没有在类似约束下（分区保序 + 批量写 + 主从延迟敏感）跑通过「worker 数 2~4 + batch size 800~1500」这个组合的实战经验？期望看到的回答形态：具体参数组合 + 对应的吞吐/P99/主从延迟数据 + 你认为瓶颈的拆解比例。

环境参数汇总

• Kafka 16 分区，消费组 8 实例，每实例 4 worker，partition 1:1 绑定
• HikariCP maxSize=16，rewriteBatchedStatements=true
• MySQL 8.0.32，InnoDB，buffer_pool_size=32G，redo log=1G
• 主从同机房，复制用半同步（rpl_semi_sync_master_wait_no_slave=OFF，即异步但带确认）
• 压测工具：自研 JMH 风格脚本，固定 5000 条消息/轮，跑 20 轮取 P50/P99