MQ Producer 攒批窗口未到期、超时先触发：整批重试、拆条重试、还是直接丢弃？线上怎么定的？

背景

我在团队里维护一套自研 MQ Producer SDK（类似 Kafka Producer 的定位），核心特性之一是攒批：maxBatchSize=512、maxWaitMs=50（先到先发）。业务方在攒批窗口内陆续 send() 进 300~500 条消息，攒满或到时间后一次性 flush 到 broker。

同时，SDK 对外暴露一个 deliveryTimeoutMs=3000——一条消息从 send() 到 ack 回来（或明确 nack）的最长等待。这是业务方做超时补偿的锚点。

现象（痛点）

上周压测时复现了一个尴尬的时序冲突：

1. t=0ms：第 1 条消息入队，攒批窗口开始计时（50ms）。
2. t=10ms~t=48ms：陆续有 400+ 条消息入队，batch 还没满（maxBatchSize=512）。
3. t=50ms：攒批窗口到期，batch 带着 407 条消息发出。
4. t=50ms~t=3050ms：broker 侧 GC 卡了 2.5s，没有回 ack。
5. t=3050ms：deliveryTimeoutMs 到期，SDK 触发超时。

此时 SDK 面临一个选择：这 407 条消息该怎么处理？

• 方案 A：整批重试。风险——broker 可能已经收到了前 200 条（只是 ack 没回来），重发会重复。除非 broker 支持 idempotent，否则业务方自己得去重。
• 方案 B：拆成单条重试。风险——丢了攒批的吞吐优势（512 条变 407 次单发），而且如果 broker 只回了前 100 条的 ack，剩下 307 条拆条重试又回到问题原点。
• 方案 C：直接放弃，抛超时异常给业务方。最"干净"，但业务方 407 条消息全丢了，补偿成本极高。
• 方案 D：等攒批窗口自然结束再统一重试。但 deliveryTimeoutMs=3000 已经到期了，再等 50ms 虽然不多，语义上已经违约了。

已尝试的排查与结果

1. 我们目前线上用的是方案 A + 要求业务方幂等：整批重发，SDK 在 header 里塞 messageId，broker 侧去重窗口 5 分钟。压测下重复率 <0.1%，但业务方吐槽"我凭什么为 SDK 的超时策略写去重逻辑？"
2. 试过把 maxWaitMs 从 50ms 缩到 10ms（让攒批窗口远小于超时），压测吞吐掉了 18%（单批从 400 条降到 80 条），broker 侧 QPS 反而升了。
3. 试过把 deliveryTimeoutMs 拉长到 10s，但业务方说"我 3s 就要拿到结果做后续流程，你 10s 我这边整个链路都超时了"。

期望得到的答案形态

1. 你们线上 MQ Producer（Kafka / RocketMQ / 自研）在「攒批窗口 × 超时 × 重试」这个三角里，最终选了哪个方案？为什么？
2. 如果选了「整批重试 + 业务方幂等」，你们怎么界定 SDK 与业务方的责任边界——SDK 文档里怎么写、异常语义怎么设计，才能让业务方接受"你需要自己幂等"这件事？
3. 有没有人做过更细粒度的 batch 内 ack 追踪（比如 broker 逐条回 ack，SDK 只重试未 ack 的那部分）？开销多大？
4. deliveryTimeoutMs 这个参数，在攒批场景下，你们计时起点是第一条 send() 还是 batch flush 的那一刻？这个 1~50ms 的差异在你们的线上有没有实际影响过？

欢迎贴配置、贴压测数据、贴 SDK 源码片段。越具体越好，"我们就是这么干的"比"理论上应该怎样"有价值十倍。

相关参考（社区里已有讨论，但没直接覆盖这个三角交互）：

• 《超时与重试：高并发后端最容易翻车、却最少被认真讨论的两件事》里提到超时和重试是容量规划的一部分；
• 《中间件客户端该不该「替用户做决定」？》里讨论了攒批与重试的边界划分。