生产者批量发送如何提升吞吐？
简化版
批量发送把多条消息合并为更少的网络请求和系统调用，并提高压缩率，因此提升吞吐、降低单条开销。代价是等待凑批增加延迟、占用内存，失败时可能整批重试；要联合调整 batch bytes、linger、压缩、并发在途和 ACK 语义。
详细版
通常按目标分区分别积累批次，达到字节/条数阈值或 linger 到期即发送。批次上限应受 Broker 请求大小、消息大小与内存预算约束；高吞吐流量可快速填满批次，低流量则主要由 linger 决定延迟。
发送重试必须保持 eventId 和生产者序列，避免重复与乱序；回调要能识别批次中每条消息结果。监控 batch fill ratio、records/request、compression ratio、queue time、ACK P99、buffer exhaustion 和错误率，并用真实消息压测吞吐与端到端延迟。
完整版教学
一、批量为什么省资源
一条一请求会重复支付协议头、TLS、网络往返和系统调用成本。批量让固定成本由多条消息分摊，连续相似数据也更易压缩。Broker 顺序追加大块数据通常比许多小写更高效。
心法：批量是在吞吐、等待时间和失败影响范围之间交换，不是免费的性能开关。
二、凑批触发条件
send when:
batch_bytes >= 64KB
OR record_count >= 500
OR now - first_record_time >= 5ms实际客户端常按分区建 batch；同一时刻写很多分区会形成多个半空批次。linger 是最大等待而非每批固定睡眠，高流量下可能立即填满。
三、数字推演
假设每次请求固定处理开销 0.2ms，逐条发送 1000 条的累计固定开销约 200ms；每批 100 条只需 10 次请求，累计约 2ms。它比较的是累计工作量，不代表存在并发时的墙钟耗时；真实吞吐还受序列化、带宽与 Broker ACK 限制，但数量级差异说明批量价值。
| 参数增大 | 收益 | 风险 |
|---|---|---|
| batch bytes | 吞吐/压缩提高 | 内存、失败批次大 |
| linger | 更易凑满 | 低流量延迟 |
| in-flight | 链路利用率 | 乱序/内存 |
| compression | 带宽下降 | CPU 增加 |
四、延迟如何组成
端到端生产延迟包括本地排队、凑批、发送、Broker 复制确认。把 linger 从 0 调到 20ms，低流量消息最多可能额外等待接近 20ms；高流量批次很快填满则影响较小。必须看 P99，而非只看平均吞吐。
紧急消息可使用独立生产者或 Topic，不应频繁 flush 公共生产者破坏所有批次效率。
五、失败与重试边界
整批请求超时属于结果未知，Broker 可能已写入。重试复用 eventId，并启用幂等 producer 的 epoch/sequence 能力；消费者仍要幂等。不同批次并发在途时，旧批重试可能晚于新批，需依赖客户端顺序保证或限制 in-flight。
单条序列化失败应在入批前隔离，不能让一条坏消息使整个批次永远重试。
批次字节上限必须小于客户端和 Broker 的请求限制，并为协议头留空间；只按消息正文相加，可能在发送时才发现整批超限。
六、内存与背压
批次存于客户端 buffer；Broker 变慢时积累会耗尽内存。应设置总 buffer 上限和阻塞/失败策略，并让上游感知背压，不能无界排队。100 个分区各保留 64KB 半空批次，至少占约 6.4MB，尚未计对象开销。
监控缓冲区可用量、等待线程、批次填充率、压缩率和发送队列年龄。参数变更应逐步灰度。
七、常见误区与追问
- 误区：batch 越大吞吐一定越高。 Broker 限制、内存和延迟会成为新瓶颈。
- 误区：linger 会让每条消息固定等待。 批次提前填满可立即发送。
- 误区：批量 ACK 代表业务完成。 只表示达到 Broker 确认边界。
- 误区：超时后换 ID 重发最安全。 会破坏去重并制造重复。
- 追问：如何兼顾紧急消息？ 分离通道或生产者，避免全局 flush。
- 追问：低流量 Topic 怎么调？ 使用较小 linger/batch，接受较低填充率。
- 追问：压缩为何与批量相关？ 批内相似数据更多，固定头与字典可共享。
八、加强记忆
生产批量按“分区凑批—大小/时间触发—压缩发送—复制 ACK—幂等重试”理解。调参同时观察填充率、排队延迟、内存和错误；高吞吐靠分摊固定成本，低延迟则需限制等待，二者必须用真实负载找平衡点。