go kafka生产者吞吐上不去主因是默认参数过于保守：batch.size=16kb过小、linger.ms=0禁用攒批、未设buffer.memory致缓冲区满，导致每条消息单独发包，网络小包多、broker压力大、延迟高；必须调优批量参数并复用producer实例。
为什么Go Kafka生产者吞吐上不去？不是代码写错，是batch.size和linger.ms太保守
默认配置下每条消息都单独发，网络小包多、Broker压力大、延迟高。confluent-kafka-go默认batch.size=16384、linger.ms=0，sarama默认Flush.Frequency=0（即立即发送），这在日志类小消息场景下完全不适用。
关键点在于：批量不是“可选优化”，而是Kafka吞吐的物理基础。没批量，就等于放弃TCP窗口、绕过网卡DMA、硬扛系统调用开销。
-
linger.ms=0：有消息就立刻发，彻底放弃攒批机会 -
batch.size=16KB：对平均200B的日志消息来说，要攒80+条才触发，实际常因超时提前发，但超时又是0，结果就是单条发 - 没设
buffer.memory：突发流量直接打满缓冲区，触发阻塞或丢弃
confluent-kafka-go怎么配出真实高吞吐？按消息大小和延迟容忍来调
假设单条消息平均200B、允许10ms内延迟，推荐这样设：
config := &kafka.ConfigMap{
"bootstrap.servers": "kafka-broker:9092",
"acks": "all",
"batch.size": 65536,
"linger.ms": 10,
"compression.type": "lz4",
"buffer.memory": 33554432,
"max.in.flight.requests.per.connection": 5,
}
注意：acks="all"不会拖慢吞吐——只要ISR副本同步快，linger.ms和批量已覆盖延迟成本；max.in.flight.requests.per.connection=5比默认1提升管道并发，但别设太高（>10）否则重试混乱；retries建议保持默认或设为3，配合enable.idempotence=true更稳，而不是盲目加大重试次数。
sarama里批量控制逻辑和confluent不同，得盯紧Flush参数
sarama不用batch.size和linger.ms，它靠Flush.Frequency和Flush.Messages触发批量。默认两者都是0，等于禁用批量。
-
Flush.Frequency=500*time.Millisecond：不管攒够没，每500ms强制刷一次 -
Flush.Messages=1000：单批最多1000条，防内存撑爆 -
Producer.Compression=sarama.CompressionSnappy：压缩能压掉30%–50%网络流量 - 别漏设
Producer.Return.Successes=true，否则SendMessages()不返回成功结果，你根本不知道发没发成
如果你用SyncProducer，它内部会等Broker响应，但批量仍由Flush控制；AsyncProducer则更依赖Input()通道和Successes()/Errors()监听，别忘了启动goroutine消费这两个channel。
高频NewProducer导致FD耗尽或TIME_WAIT堆积，必须复用实例
每次NewSyncProducer或NewProducer都会建新连接，QPS上千时很快打满文件描述符。这不是“连接池”问题，而是根本没复用。
- 全局只初始化1个
producer实例，所有goroutine共用 - 如果业务需多topic或多broker，也应复用同一config创建多个producer，而非每次new
- 关闭时机必须明确：
defer producer.Close()只适合短命命令行；长服务要用sync.Once或信号监听优雅关闭 - 注意sarama的
AsyncProducer关闭前要先AsyncClose()再Wait()，否则可能丢消息
真正卡住吞吐的，往往不是Kafka本身，而是Go侧连接管理松散、批量配置形同虚设、错误处理缺失——这些细节不抠，调参再多也没用。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
