kafka生产者异步发送依赖批量缓冲、压缩、重试和确认机制协同优化；batch.size与linger.ms需配合调整，推荐batch.size设32–64kb、linger.ms设5–50ms；启用lz4压缩并增大buffer.memory至64–128mb可提升吞吐。
Kafka 生产者异步发送本身不是靠“开启开关”实现的，而是由批量缓冲、压缩、重试和确认机制共同驱动的。真正提升吞吐性能的关键，在于让这些机制高效协同，既不卡主线程，也不丢消息。
batch.size 与 linger.ms 要一起调，不能单边加
这两个参数决定消息何时打包发出，是吞吐与延迟平衡的第一关。
- batch.size 默认 16KB：适合单条消息约 200B 的场景；若消息普遍更小（如日志类 50–100B），可设为 32KB 或 64KB，让每批装更多条，减少网络请求次数
- linger.ms 默认 0（来一条发一条）：容易产生大量小批次；设为 5–20ms 是通用推荐值；匀速写入（如订单状态流）可尝试 30–50ms，但需验证业务端是否感知延迟
- 只加大 batch.size 不设 linger.ms → 高并发仍频繁发小批；只设 linger.ms 不调 batch.size → 低流量时消息可能卡在缓冲区超时才发出
用 lz4 压缩 + buffer.memory 扩容，缓解网络与内存瓶颈
压缩在 Producer 端完成，不增加 Broker 压力，却能降低传输体积和磁盘 IO。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 推荐配置 compression.type=“lz4”：CPU 开销低、解压快、压缩率适中，实测比 snappy 更均衡
- buffer.memory 默认 32MB：若消息体较大（如含 base64 图片）或持续高吞吐，建议升至 64MB 或 128MB，避免 RecordAccumulator 满导致 send() 阻塞或抛异常
- 注意：对极小消息（
启用幂等性 + 合理设置飞行请求数与重试策略
异步不等于不可靠，可靠性由 ack、重试和幂等机制兜底。
- 设 enable.idempotence=true：自动启用幂等生产者，保障不重不丢，同时将 max.in.flight.requests.per.connection 限制为 5，兼顾吞吐与分区顺序
- acks=all：要求 ISR 中所有副本都写成功才返回确认，是强可靠前提
- retries 建议设为 Integer.MAX_VALUE（2147483647），配合 retry.backoff.ms=100，实现自动退避重试
回调处理要轻量，避免阻塞或丢失异常
回调函数运行在 Kafka 的 Sender 线程中，逻辑必须简洁，否则会拖慢整个发送链路。
- 不要在回调里做耗时操作（如远程调用、复杂计算、数据库写入）；只做日志记录、指标上报、失败消息暂存等轻量动作
- 异常必须显式捕获并处理，比如落库重试队列、触发告警、或标记后异步补偿；不能只打印日志就忽略
- 如果不需要结果反馈，直接 producer.send(record) 即可；但线上环境强烈建议带回调，便于问题定位
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
