批量写入的「端到端可见性延迟」预算怎么拆：攒批窗口 W、单批耗时 T、主从复制 P99 D 三段，压哪一段 ROI 最高？

【背景】 我负责一条实时数据落库链路：Kafka → 自研消费端攒批 → MySQL 8.0.32（单主 + 1 从，InnoDB，binlog_format=ROW，sync_binlog=1，innodb_flush_log_at_trx_commit=1），查询接口走从库。业务方有一个硬性 SLA：数据从 Kafka 产生到可从查询接口读到，P99 ≤ 3 秒。

当前参数与实测：

• 攒批窗口 W = 500ms（攒满 2000 条或 500ms 先到先走）
• 单批写入耗时 T = 80ms（multi-row INSERT 2000 行，P50）
• 主从复制 P99 延迟 D = 1.8s（正常流量下）
• 查询接口额外延迟 L ≈ 5ms（可忽略）

正常流量下：W + T + D ≈ 0.5 + 0.08 + 1.8 = 2.38s，勉强达标。

【现象】 上周流量高峰（日常 3 倍），主从复制 P99 延迟从 1.8s 涨到 3.5s（大事务 binlog 回放变慢），总 P99 = 0.5 + 0.08 + 3.5 = 4.08s，超 SLA 36%。

【已尝试的三个方向与实测结果】

方向 1：压 W（500ms → 100ms）

• W 节省 400ms
• 但 T 从 80ms 涨到 120ms（小 batch 写入效率下降，commit 开销占比升高）
• 净省 280ms，总 P99 降到 3.80s，仍不达标
• 结论：W 和 T 是负相关的，压 W 有上限

方向 2：改读主库

• 去掉 D，总 P99 = 0.5 + 0.08 = 0.58s，达标
• 但主库查询 QPS 从 0 涨到 ~500，主库 CPU 从 40% 涨到 75%
• 结论：延迟收益最大，但 CPU 风险太高，不敢上线

方向 3：拆 batch（2000 条 → 500 条/批）

• 单事务 binlog 体积降 4 倍，D 从 3.5s 降到 1.2s
• 但批次数 ×4，总写入耗时 ×4（80ms×4 = 320ms）
• 总 P99 = 0.5 + 0.32 + 1.2 = 2.02s，达标
• 代价：写入吞吐从 8000 行/s 降到 5600 行/s（commit 开销 ×4），降 30%

【已做的排查】

• 用 performance_schema.replication_connection_status 监控从库回放，确认 D 的瓶颈是「单事务 binlog 体积」而非「网络带宽」或「从库 CPU」
• 压测了 W=100/200/500ms 三档，T 分别为 120/100/80ms，确认 W 和 T 是负相关的
• 拆 batch 到 500 条/批后，主从延迟确实降到 1.2s，但写入吞吐降 30%

【期望得到的答案形态】

1. 有没有一个量化的「延迟预算分配」模型，能根据 SLA（3s）、流量特征（日常/高峰倍数）、硬件约束（主库 CPU 上限、从库回放能力）自动算出 W、batch_size、是否读主的最优组合？还是说这本质上是一个多目标优化问题，没有闭式解，只能靠压测网格搜索？

2. 压 W、改读主、拆 batch 三个方向的 ROI 排序，在什么条件下哪个方向 ROI 最高？我目前的直觉是：日常流量压 W 性价比最高，高峰流量拆 batch 性价比最高，但缺少量化依据。如果你们团队有类似场景，是怎么定的？

3. 有没有人做过「batch size 与主从复制 P99 延迟」的定量关系？比如 batch_size 从 500→2000，D 从 X 涨到 Y，这个曲线的形状是什么样的（线性？对数？阶跃？有没有一个「临界 batch size」超过后 D 急剧恶化）？

【参考】

• 站内 #935 讨论了大事务导致主从延迟（2.3M 行 UPDATE 拖垮 SQL 线程），但角度是拆事务，没有讨论「延迟预算如何在 W/T/D 三段间分配」
• 站内 #1600 讨论了攒批窗口怎么定（100 条 vs 10ms），但只聚焦吞吐 vs 延迟的 tradeoff，没有把主从复制延迟纳入端到端预算
• 站内 #738 讨论了 batch size 与 worker 并发度的联合最优解，但没有讨论从库延迟这个约束