【背景】 高并发后端里，批量写几乎是标配：DB batch insert、Kafka 攒批发送、日志异步落盘、MQ 批量 ack……但一个很朴素的问题，很多团队其实从来没认真算过：攒多少、等多久、到底谁说了算？
我最近复盘一个线上问题：订单服务往 MySQL 写流水，用的是「攒满 200 条或攒满 50ms，谁先到谁 flush」的双阈值策略。日常 QPS 3000 时表现完美，P99 写延迟 8ms。但上周大促压测 QPS 拉到 12000 时，P99 突然飙到 220ms，DB 端看到的是「一批 200 条的大事务」密集到达，锁等待直接打满。根因不是单条慢，而是攒批窗口在高 QPS 下把"时间窗口"压没了，变成了纯 size 驱动，批次大小没有上限保护。
这个坑其实很典型：双阈值策略在低 QPS 下 time 先到（攒不满 200 条但 50ms 到了），批次小、延迟低；在高 QPS 下 size 先到（200 条瞬间攒满，远不到 50ms），批次大、锁持有时间长、下游压力集中。同一个配置，低峰安全、高峰爆炸。
【常见分歧——我至少见过四种做法】
- 纯 size 驱动：攒满 N 条就 flush。简单、可预测，但低峰期最后一条数据要等很久才能落盘（用户等的是"我那条"，不是"那 200 条"）。
- 纯 time 驱动：每 T 毫秒检查一次，有多少发多少。延迟可控，但高峰期可能一次攒出几千条，下游直接被打穿。
- 双阈值（size OR time）：最主流，但两个阈值之间的"交互效应"很少被认真分析——就是上面我说的那个问题：高 QPS 下 time 阈值形同虚设，退化成纯 size 驱动。
- 自适应 / 动态窗口：根据队列深度、下游 RT 动态调整批次大小。理论上最优，但实现复杂，调参成本极高，我见过两个团队做到一半放弃。
- 按业务语义硬编码：支付单攒 10 条、日志攒 1000 条、审计攒 50 条。最合理，但每个业务都要单独定，维护成本高。
还有一种我特别想听到的：有人真的从下游承受能力倒推过 batch size 吗？ 比如先测出 DB 单次 INSERT 200 条的 P99 锁持有时间是 12ms，再算出在目标 TPS 下允许的批次到达频率，反推出"攒批窗口应该多大"。我猜大部分团队没做过这个推导，阈值是"看着别人抄的"或者"压测时调到一个不报错的值"。
【我的倾向与理由】
我倾向 「双阈值 + 批次大小硬上限 + 从下游倒推」 的组合，理由：
- 双阈值是下限保护：time 阈值保证低峰期不延迟，size 阈值保证高峰期不空发（一次只发 3 条太浪费）。
- 批次大小硬上限是上限保护：不管 size 阈值设多大，单次 flush 不能超过 M 条。这是我上面那个坑的直接教训——200 条的批次在 12000 QPS 下变成"持续 200 条大事务"，没有上限保护就是裸奔。
- 从下游倒推而不是从上游正推：上游"我想攒 200 条"和"DB 能扛住 200 条/批 × 60 批/秒"是两回事。前者是开发者的直觉，后者是容量规划。我习惯先拿 EXPLAIN ANALYZE + sysbench 把下游的"单批处理时间"和"并发批处理上限"摸出来，再反推。
但我也承认这个方案有个硬伤：下游不是静态的。DB 的锁持有时间会随表大小、并发度、buffer pool 命中率波动。你倒推出来的"安全批次大小"只在某个负载区间内成立，负载一变就失效。所以严格来说，batch size 不是一个"配置"，而是一个"运行时决策"——这才是真正难的地方。
【想听大家】
- 你们团队的攒批策略是哪种？阈值怎么定的——是算出来的、压测调出来的、还是抄的？
- 有没有因为攒批窗口不合理导致过线上问题？（我猜不少人有，只是没当"攒批问题"复盘，而是当"DB 慢"或"Kafka 堆积"复盘了。）
- 高 QPS 下双阈值退化成纯 size 驱动，你们怎么处理的？加硬上限？动态调 size？还是干脆换架构（比如分片写入）？
- 有没有人真的做过"从下游承受能力倒推 batch size"的推导？过程是什么样的？
我抛这个题，核心是想把"攒批窗口"从一个"调参项"拉回到"容量规划项"——它跟连接池大小（引用 #18 那篇聊得很透）、超时预算（#23 那篇）本质上是同一类问题：不是"设一个值"，而是"在下游约束下求一个安全区间"。
参考：#18《连接池不是越大越好》里对"参数不是越大越好、要在下游约束下找安全区间"的分析，和攒批窗口是同一个逻辑。