提升 kafka 生产者吞吐量的关键是批量机制、缓冲控制和资源复用，核心参数为 batch.size 与 linger.ms 的协同调优：batch.size 默认 16kb，可据消息大小调整；linger.ms 默认 0，建议设为 5–20ms 平衡延迟与批次大小；启用 lz4 压缩可降低传输负载。

提升 Kafka 生产者吞吐量，核心在于让消息“聚起来、压下去、发得稳”。异步发送本身不直接提速，真正起作用的是背后的批量机制、缓冲控制和资源复用。关键不是多线程并发发消息，而是让每条网络请求承载更多有效载荷。

batch.size 与 linger.ms 的协同调优

这两个参数共同决定“什么时候发”，是吞吐量优化的起点。单独调大 batch.size 可能导致小流量下消息长期滞留；只设 linger.ms 又可能在高并发时触发过于频繁的小批次。

• batch.size 默认 16KB（16384 字节）：适合中等消息体。若平均单条消息约 200B，意味着一批约 80 条才触发发送；若消息普遍小于 100B，可逐步提高到 32KB 或 64KB，提升单批条数
• linger.ms 默认 0：即“有就发”，容易产生大量小包。设为 5–20ms 是常见平衡点——既避免明显延迟，又给小流量场景争取凑满批次的机会
• 实际效果取决于业务写入节奏。突发写入（如日志打点）更适合低 linger.ms + 中等 batch.size；匀速写入（如订单状态流）可适当提高 linger.ms 至 50ms，进一步摊薄网络开销

启用压缩降低传输负载

压缩发生在 Producer 端内存中，不增加 Broker 负担，却能显著减少网络带宽占用和磁盘 IO，间接提升整体吞吐能力。

• lz4 是首选：CPU 开销低、压缩率适中、解压速度快，实测比 snappy 更适合通用场景；gzip 压缩率高但 CPU 消耗大，仅在带宽极度受限且 CPU 富余时考虑
• 配置方式简单：props.put("compression.type", "lz4")
• 注意：压缩对极小消息（

Sender 线程与缓冲区管理

异步发送依赖 Sender 后台线程从 RecordAccumulator 中取批发送。它的效率受缓冲容量和刷新频率影响。

• buffer.memory 默认 32MB：控制整个生产者可用缓冲总量。若持续高吞吐或消息体较大，需按需上调（如 64–128MB），避免因缓冲满而阻塞主线程
• max.in.flight.requests.per.connection 默认 5：限制每个连接上未确认的请求数。设为 1 可保证分区级顺序，但会限制吞吐；设为 5 或更高（配合幂等性）可提升并发发送能力
• 开启幂等性（enable.idempotence=true）后，Producer 自动将 max.in.flight.requests.per.connection 限制为 5，既保障不重不丢，又维持较高吞吐

回调处理不拖慢主线程

使用带回调的异步发送（Callback）是推荐实践，但回调逻辑本身不能成为瓶颈。

• 回调函数应轻量：仅记录日志、指标统计或触发简单告警；避免同步 I/O、复杂计算或阻塞操作
• 若需失败重试，建议交由独立线程池或消息队列异步处理，而非在回调中循环 retry
• 异常捕获要具体：区分 NetworkException（可重试）和 SerializationException（应提前修复），避免无效重试拖慢整体流速