吞吐上不去主因是sarama生产者默认参数未调优：batch.size过小（16kb）、linger.ms=0禁用攒批、未启用压缩、高频重建syncproducer实例。必须覆盖5个关键参数——batch.size=64kb、lingerms=10、compression=lz4、buffer.memory=32mb、maxinflight=5+idempotent=true，并确保producer全局单例。
吞吐上不去，90% 是生产者参数没调对，不是代码写得不好，也不是 Kafka 集群不行。
为什么 sarama.NewSyncProducer 吞吐卡在每秒几百条
常见现象：本地跑通、压测掉速、CPU 和网络都不高，但 SendMessage 耗时飙升，Broker 端连接数暴涨、TIME_WAIT 堆积。
根本原因不是并发低，而是默认配置让每条消息都单独发包：
-
batch.size=16384（16KB）太小 —— 日志类消息平均 200B，意味着每 80 条才凑满一批 -
linger.ms=0关闭攒批 —— 有消息立刻发，彻底放弃批量优化机会 -
compression.type=""（空）没开压缩 —— 小消息密集场景下，网络带宽白白浪费 40%+ - 高频创建/销毁
SyncProducer实例 —— 每次都重建 TCP 连接，耗尽文件描述符
sarama 生产者必须覆盖的 5 个关键参数
以单条消息均值 200–500B、端到端延迟 ≤10ms 为典型场景，这些参数要硬性覆盖默认值：
-
config.Producer.Batch.Size = 65536（64KB）—— 确保单批至少装下 128–320 条消息 -
config.Producer.LingerMS = 10—— 给网络拼批留出确定性等待窗口 -
config.Producer.Compression = sarama.CompressionLZ4—— 比 Snappy 更快，CPU 开销可控 -
config.Producer.Buffer.Memory = 33554432（32MB）—— 防突发流量打满内存缓冲区 -
config.Producer.MaxInFlight = 5且config.Producer.Idempotent = true—— 提升管道并行度 + 保证幂等性，比盲目设retries=INT_MAX更稳
消费者端“慢”往往不是并发低，而是处理逻辑阻塞
Consumer.Poll() 返回快不代表消费快 —— 如果回调里直接写 DB、调 HTTP、解析大 JSON，就会拖垮整个消费节奏，触发 max.poll.interval.ms 超时、反复 Rebalance。
- 别在
Poll回调里做任何同步 IO；拆成chan+ worker goroutine 池异步处理 -
config.Consumer.Fetch.Min = 1024和config.Consumer.Fetch.MaxWait = 100要配对 —— 避免空轮询或过度等待 - 分区数 ≠ Goroutine 数：一个 Partition 只能被一个 Consumer 实例消费；想真正并行，得靠增加 Topic 分区 + 多实例同 Group
- 首次上线慎用
auto.offset.reset="earliest"—— 全量重放可能压垮下游；建议先用"latest"，再按需人工Seek
kafka-go vs sarama：选哪个更省心
如果追求开箱即用和低维护成本，kafka-go 更适合新项目：
- 纯 Go 实现，无 cgo 依赖，部署简单
- 天然支持
context，超时控制和取消操作更直观 - 内置
Writer.Balancer（如LeastBytes）自动分发，不用手动算 key hash - 默认就启用批量写入（基于
MaxBytes和BatchTimeout），无需额外调参
而 sarama 更适合已有深度定制需求、需要细粒度控制协议层行为的老系统 —— 但前提是愿意花时间调参、踩坑、读源码。
真正容易被忽略的是：无论用哪个库，**生产者初始化必须是全局单例**。每次发消息都 new 一个 producer，等于把性能优化全白做了。
