默认吞吐上不去主因是batch.size=16KB过小且linger.ms=0关闭攒批，应调为64KB和10ms，并启用lz4压缩、增大buffer.memory至32MB、设置max.in.flight=5及enable.idempotence=true。
默认配置下吞吐上不去，不是代码问题，而是 batch.size 和 linger.ms 没调对 —— 这是 90% 的 Go-Kafka 生产者性能瓶颈所在。
为什么 sarama.NewSyncProducer 吞吐卡在每秒几百条
常见现象：本地跑通了，一压测就掉速，CPU 不高、网络不饱和，但 SendMessage 耗时飙升、Broker 端连接数暴涨、TIME_WAIT 堆积。根本原因不是并发不够，而是每条消息都单独发包：
-
batch.size=16384（16KB）太小，日志类消息平均 200B，意味着每 80 条才凑满一批 -
linger.ms=0关闭攒批，有消息立刻发，彻底放弃批量优化机会 - 没开压缩，
compression.type默认空，小消息密集场景下网络带宽白白浪费 40%+ - 每次新建
SyncProducer都重建 TCP 连接，高频创建/销毁耗尽文件描述符
confluent-kafka-go 或 sarama 高吞吐必须改的参数
以单条消息均值 200–500B、允许端到端延迟 ≤10ms 为典型场景，这些参数要硬性覆盖默认值：
-
batch.size设为65536（64KB），确保单批至少装下 128–320 条消息 -
linger.ms设为10，给网络拼批留出确定性等待窗口 -
compression.type选lz4（比snappy更快，CPU 开销可控） -
buffer.memory至少33554432（32MB），防突发流量打满内存缓冲区 -
max.in.flight.requests.per.connection设为5，提升管道并行度（默认是 1） - 务必启用幂等：
enable.idempotence=true，比盲目设retries=INT_MAX更稳
消费者端“慢”往往不是并发低，而是处理逻辑阻塞
Consumer.Poll() 返回快不代表消费快 —— 如果回调里直接写 DB、调 HTTP、解析大 JSON，就会拖垮整个消费节奏，触发 max.poll.interval.ms 超时、反复 Rebalance：
立即学习“go语言免费学习笔记（深入）”；
- 别在 Poll 回调里做任何同步 IO；拆成
chan+ worker goroutine 池异步处理 -
fetch.min.bytes和fetch.max.wait.ms要配对：比如fetch.min.bytes=1024+fetch.max.wait.ms=100，避免空轮询或过度等待 - 分区数 ≠ Goroutine 数：一个 Partition 只能被一个 Consumer 实例消费；想真正并行，得靠增加 Topic 分区 + 多实例同 Group
- 首次上线慎用
auto.offset.reset="earliest"，全量重放可能压垮下游；建议先用"latest"，再按需人工Seek
go-stash 是 Kafka → ES 管道最省心的落地选择
如果你的数据流终点是 ElasticSearch，别自己写消费+转换+索引逻辑 —— go-stash 是专为此场景设计的轻量级管道，二进制即用，吞吐比 logstash 高 5 倍：
- 配置里
Conns * Consumers别超 Kafka Topic 总分区数，否则空转线程浪费资源 -
Processors推荐设为Conns * Consumers * 2，留足过滤/转换余量 -
MinBytes/MaxBytes控制从 Kafka 拉取的数据块大小，默认1048576~10485760（1M–10M）适合千兆网卡，万兆可往上提 - 字段过滤用
Action: drop比在 Go 代码里 if-else 更高效；Action: transfer比手动 map 赋值更安全
真正难的从来不是“怎么连上 Kafka”，而是让每条消息在毫秒级延迟内完成采集、传输、过滤、落库 —— 这些参数组合和线程模型的微妙平衡，才是高吞吐管道的隐性门槛。
