推荐配置为batch.size=32768+linger.ms=20，兼顾吞吐与延迟；需根据消息平均大小动态调低linger.ms（如200B消息建议设5~10），并用kafka-producer-perf-test.sh实测p99延迟。
batch.size 和 linger.ms 怎么配才不拖慢又不空等
单纯调大 batch.size 不一定提升吞吐，反而可能让小流量场景下消息“卡住”；linger.ms 设太高，低峰期延迟明显上升。关键在平衡：主流生产环境推荐 batch.size=32768（32KB）+ linger.ms=20，这个组合在多数中高并发场景下能稳定攒够一批消息，又不会明显增加端到端延迟。
注意两个易错点：
-
linger.ms是“最大等待时间”，不是固定延迟——只要batch.size满了，立刻发，不用等满 - 如果消息体普遍很小（比如平均 200B），那即使设
batch.size=32768，也要约 160 条才能凑满，此时linger.ms就成了实际瓶颈，建议同步调低到5或10 - 测试时别只看吞吐数字，用
kafka-producer-perf-test.sh配合--producer-props linger.ms=20 batch.size=32768对比压测，观察 p99 延迟是否突增
compression.type 选 snappy 还是 lz4
snappy 和 lz4 都是低 CPU 开销、中等压缩率的选项，但行为有差异：lz4 在小消息（snappy 更成熟，兼容性略好。生产环境优先选 lz4，配置项就是 compression.type=lz4。
必须避开的坑：
立即学习“Python免费学习笔记（深入）”；
- 别用
gzip——CPU 占用翻倍，尤其在容器环境容易触发限频 - 别在 producer 端设
compression.type=none然后指望 broker 压缩——broker 不会重压缩，该传多少字节还是多少字节 - 如果消费者是旧版客户端（如 kafka-python lz4 解码，否则会报
UnsupportedCompressionTypeException
异步发送一定要配 callback 吗
不配 callback 的纯异步（即只调 producer.produce() 不跟回调）看似吞吐最高，但等于放弃所有失败感知——网络抖动、目标 partition 不可用、序列化失败，全被静默吞掉。真实线上系统几乎没人这么干。
正确姿势是用 callback，但要注意三点：
- callback 函数必须快：里面只做日志记录或写入本地队列，**不要**调外部 HTTP 接口或数据库写入，否则阻塞 Sender 线程，反向拖垮吞吐
- confluent-kafka 的
delivery_report回调里，err为None才代表成功；kafka-python 的add_callback/add_errback是分离的，别漏写add_errback - 别依赖
producer.flush()等待全部 callback 执行完——它只保证消息发出，不保证 callback 返回。真要强一致性，得自己维护 pending 列表 + 超时机制
buffer.memory 和 queue.buffering.max.messages 容易被忽略的副作用
buffer.memory（kafka-python）和 queue.buffering.max.messages（confluent-kafka）看着是“加大缓冲”，但设太大反而引发问题：内存占用飙升、OOM 风险、GC 压力增大，尤其在容器部署时可能被 kill。
经验值参考：
- 单实例生产者，QPS 在 1k~5k 之间，
buffer.memory=33554432（32MB）足够；超 10k QPS 再考虑加到 64MB -
queue.buffering.max.messages默认是 100000，但如果你每秒只发 200 条，设成 100 万毫无意义，还占内存 - 这两个参数和
batch.size、linger.ms是联动的：缓冲区越大，越容易攒够 batch，但也意味着故障时未发送消息更多——得同步评估数据丢失容忍度
最常被跳过的检查项：没监控 producer.metrics() 里的 buffer-total-bytes 和 record-queue-time-avg。数值持续高位，说明要么下游堵了，要么你配得太激进。
