Kafka消费者需手动提交offset并调优session.timeout.ms为45s、heartbeat.interval为15s，避免因GC或网络抖动触发rebalance；FetchMaxBytes须显式设为10MB并同步调大broker限制，禁用AutoCommit与sync.Pool缓存Message。
Kafka + Go 能撑住每秒数万消息，但默认配置和随手写的消费者会崩得比想象中快——关键不在语言，而在连接复用、批量提交和 offset 管理方式。
为什么 consumer.GroupSessionTimeout 不能设成 30s
这是最常被改错的参数。Kafka 消费者组依赖心跳维持成员身份，session.timeout.ms（Go SDK 中对应 consumer.GroupSessionTimeout）一旦超时，broker 就会触发 rebalance。但 Go 的 kafka-go 默认心跳间隔是 session.timeout.ms / 3，如果设成 30s，实际心跳每 10s 一次；而网络抖动或 GC 停顿稍长（比如 15s），就会被踢出组。
- 生产环境建议设为
45000（45s），同时把consumer.HeartbeatInterval显式设为15000 - 别依赖
AutoCommit：它在每次拉取后立即提交 offset，若处理失败，消息就丢了；必须关掉，改用CommitOffsets手动提交 - rebalance 期间所有 handler 会被阻塞，所以业务逻辑不能卡在数据库写入或 HTTP 调用里——要异步化或加超时
如何让 kafka-go 每次 FetchMaxBytes 真正拉满
FetchMaxBytes 是单次请求最大字节数，但默认值 1048576（1MB）常被误以为“够大”，实际受三个隐性限制：broker 的 message.max.bytes、topic 的 max.message.bytes、以及客户端 FetchDefaultBytes（未显式设置时 fallback 到 1KB）。
- 务必显式设置
FetchMaxBytes: 10 * 1024 * 1024（10MB），并确认 broker 配置已同步调大 - 单 partition 拉取量还受限于
FetchMinBytes和FetchDefaultBytes：前者设太小（如 1）会导致频繁空轮询；后者影响首次 fetch 大小，建议设为512 * 1024 - 真正吞吐瓶颈常在
ReadLag：用conn.ReadPartitions或consumer.ReadMessage时，如果没及时消费完 buffer，后续 fetch 会被阻塞——要用 goroutine 分离读取与处理
为什么用 sync.Pool 缓存 Message 结构体反而拖慢性能
kafka-go 的 kafka.Message 是小对象（约 100 字节），但它的 Value 和 Headers 字段指向底层 socket buffer。直接丢进 sync.Pool 会导致 buffer 被意外复用，引发数据错乱或 panic。
立即学习“go语言免费学习笔记（深入）”；
- 绝对不要对
kafka.Message做Put操作；需要复用的是业务解析后的结构体（比如PushRequest），而非原始 Message - 高频场景下，真正该池化的对象是 JSON 解析器（
json.Decoder）或序列化 buffer（bytes.Buffer） - 如果用了
confluent-kafka-go，它的Message更重，但同样禁止池化——文档明确写 “do not reuse Message instances”
如何避免 producer 发送时堆积导致 OOM
kafka.Writer 内部有 QueueCapacity 和 BatchSize 两层缓冲，但默认值（QueueCapacity: 1000, BatchSize: 100）在突发流量下极易撑爆内存。更危险的是，WriteMessages 是同步接口，失败时不自动重试，也不限流。
- 必须设置
QueueCapacity: 10000并启用RequiredAcks: kafka.RequireAll（避免丢消息），同时配RetryBackoff: 100 * time.Millisecond - 发送前做简单限流：用
golang.org/x/time/rate.Limiter控制每秒写入条数，比靠队列背压更可控 - 监控
writer.Stats().QueuedRecords，超过阈值（比如 5000）就触发降级（如退到本地文件暂存）——这个字段不被文档强调，但它是唯一能实时反映积压的指标
高吞吐不是堆参数堆出来的，而是每个环节都得知道谁在等谁、buffer 归谁管、panic 是从哪一层透出来的。Kafka 的可靠性契约很严，但 Go 的 runtime 和网络栈不会替你兜底。
