默认Kafka生产者吞吐低主因是batch.size=16384和linger.ms=0过于保守，导致单条发包、网络开销大、Broker压力高；未启用lz4/snappy压缩进一步削弱性能。
为什么默认配置下Kafka生产者吞吐上不去
不是代码写错了，而是batch.size和linger.ms太保守——Go客户端（比如confluent-kafka-go）默认batch.size=16384、linger.ms=0，意味着每条消息都可能单独发，网络小包多、Broker压力大、延迟高。
-
linger.ms=0：有消息就立刻发，放弃攒批机会 -
batch.size过小：16KB对现代网卡和磁盘来说几乎没意义，尤其日志类小消息密集场景 - 没开压缩：
compression.type="snappy"或"lz4"能压掉 50%+ 网络流量，实测吞吐提升 2–3 倍 - Producer未复用：每次
NewProducer都建连接，高频创建/销毁导致FD耗尽或TIME_WAIT堆积
confluent-kafka-go里怎么配出真实高吞吐
别照搬文档默认值，要按你的消息体大小和延迟容忍调。假设单条日志平均 200B、允许 10ms 内延迟，推荐这样设：
config := &kafka.ConfigMap{
"bootstrap.servers": "kafka-broker:9092",
"acks": "all",
"batch.size": 65536, // 64KB 批量
"linger.ms": 10, // 等 10ms 拼更多消息
"compression.type": "lz4", // 比 snappy 更快，CPU开销略高但值得
"buffer.memory": 33554432, // 32MB 缓存，防突发打满
"max.in.flight.requests.per.connection": 5,
}
-
acks="all"不拖慢吞吐——只要Broker副本同步快，linger.ms和批量已覆盖延迟成本 -
max.in.flight.requests.per.connection=5：允许管道中最多 5 个未确认请求，比默认 1 提升并发写入能力 - 避免设
retries为很大值：重试会干扰批量节奏；建议配合幂等enable.idempotence=true更稳
消费者端卡在“慢消费”？别只怪Goroutine数量
常见现象是Consumer.Poll()返回很快，但处理逻辑卡住，导致max.poll.interval.ms超时、触发Rebalance——这不是并发不够，而是处理链路阻塞了。
- 别在
Poll回调里做DB写入、HTTP调用等同步IO：拆成chan+ worker goroutine池异步处理 -
fetch.min.bytes和fetch.max.wait.ms要匹配：比如设fetch.min.bytes=1024+fetch.max.wait.ms=100，避免空轮询或过度等待 - 分区数 ≠ Goroutine数：一个Partition只能被一个Consumer实例消费；想并行，得靠增加Topic分区数 + 启动多个Consumer实例（同组）
- 小心
auto.offset.reset="earliest"首次启动全量重放：日志类场景建议先用"latest"上线，再人工指定offset回溯
本地开发调试时Kafka连不上？先查这三处
尤其是用Docker跑Kafka+ZooKeeper时，127.0.0.1或localhost在容器内外根本不是一回事。
立即学习“go语言免费学习笔记（深入）”；
- Broker advertised.listeners 配置错：必须填容器外部可访问的IP或host，比如
PLAINTEXT://host.docker.internal:9092（Mac/Win）或宿主机IP（Linux） - Go程序连的是
localhost:9092，但Kafka容器只监听0.0.0.0:9092——网络通但协议层拒绝，错误常是EOF或connection refused -
saramaSDK版本与Kafka服务器不兼容：比如用sarama v1.32.0连 Kafka 3.x，会出现静默超时；建议统一用sarama v1.38.0+或confluent-kafka-go v2.4.0+
高吞吐从来不是调几个参数就成的事——它卡在生产者攒批策略、消费者处理流水线、Broker资源水位、甚至DNS解析延迟上。最容易被跳过的，是压测前没确认message.max.bytes和replica.fetch.max.bytes是否对齐，结果大日志直接被截断静默丢弃。
