sarama无独立OnRebalance回调，再平衡由Setup（分配前）和Cleanup（释放后）隐式驱动；漏写二者会导致重复消费或丢消息，必须配合周期性手动提交offset并禁用自动提交。
Go 语言中 Kafka 消费组再平衡不是“自动触发回调”，而是必须靠你主动在 Setup 和 Cleanup 里接管状态迁移和 offset 提交——漏掉任一环节，轻则重复消费，重则丢消息。
为什么 sarama 没有 OnRebalance 回调？
sarama 的再平衡流程是隐式驱动的：它只在分区分配前调用 Setup，在分区释放后调用 Cleanup，中间不暴露“再平衡开始/结束”这类事件。很多开发者误以为注册了 ConsumerGroupHandler 就万事大吉，结果发现消费者重启后从老 offset 继续读、或处理一半崩溃后 offset 没提交——问题就出在只实现了 ConsumeClaim，却没碰 Setup 和 Cleanup。
常见错误现象：
- 消费者扩容后，新实例一直收不到消息（旧实例没释放资源，
Setup里没关旧 channel） - 单实例运行时偶尔丢消息（
Cleanup是唯一提交点，但崩溃时根本没机会执行） - 日志里反复出现
rebalanced: lost claim for partition X却无感知（状态未清理，导致后续 claim 初始化失败）
如何正确使用 Setup 和 Cleanup？
Setup 不是初始化连接的地方，它是“交接现场”：上一个消费者刚释放分区，你马上要接手，必须确保本地状态干净；Cleanup 也不是简单收尾，它是“最后防线”：哪怕主循环卡住，这里也要尽力提交已处理完的 offset。
立即学习“go语言免费学习笔记（深入）”；
-
Setup中应：
– 关闭旧的Messages()channel（避免 goroutine 泄漏）
– 清空缓存/计数器/聚合状态（如未 flush 的 metrics）
– 可选：从外部存储（DB / Redis）加载该分区最新 offset，用claim.InitialOffset()覆盖默认起点 -
Cleanup中应：
– 先检查claim != nil（再平衡期间 claim 可能已被置为 nil）
– 调用consumer.CommitOffsets()提交当前已标记 offset
– 不要在这里做耗时操作（如 DB 写入），否则会拖慢再平衡速度
offset 提交到底该在哪做？
只靠 Cleanup 提交是危险的——它只在分区被收回时触发。如果组里只有 1 个消费者，它可能连续持有某个分区数小时，期间若进程 crash，所有未提交的 offset 全丢，重启后从上次提交点重放。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
正确做法是组合使用：
- 禁用自动提交：
config.Consumer.Offsets.AutoCommit.Enable = false（否则手动CommitOffsets和后台 auto-commit 竞争） - 启动一个 goroutine，每 5–10 秒调用一次
consumer.CommitOffsets()（注意：需传入当前所有活跃claim的 offset 映射） -
Cleanup中仍要调一次CommitOffsets，作为兜底，但加if claim != nil判断
示例片段（伪代码）：
go func() {
ticker := time.NewTicker(7 * time.Second)
defer ticker.Stop()
for range ticker.C {
offsets := make(map[string]map[int32]int64)
// 遍历当前所有 claim，收集已处理到的 offset + 1
consumer.CommitOffsets(context.Background(), offsets)
}
}()如何避免“假死”触发无谓再平衡？
Kafka 协调器判断消费者是否存活，只看两个指标：心跳是否按时发、claim.Messages() 是否在 Config.Consumer.Group.MaxHeartbeatInterval（默认 5 分钟）内返回。一旦业务逻辑阻塞（比如 HTTP 调用超时、DB 查询锁表），主 goroutine 卡在 ReadMessage 或 <-claim.Messages()，心跳就停了，协调器直接踢人。
关键对策：
- 所有耗时操作（网络 IO、DB 查询、文件写入）必须拆进独立 goroutine 处理
- 主循环只负责快速拉取消息并分发，例如：
for msg := range claim.Messages() { go handle(msg) } - 检查
Config.Consumer.Group.Heartbeat.Interval（默认 10 秒），确保你的 goroutine 启动开销远小于此值 - 若无法避免长耗时，考虑调大
MaxHeartbeatInterval，但别超过 30 分钟（Kafka 服务端有硬限制）
真正容易被忽略的是：再平衡本身不保证原子性——Setup 执行成功但 ConsumeClaim 立即 panic，会导致分区处于“半接管”状态。生产环境务必在 ConsumeClaim 外层加 recover，并记录 panic 堆栈，否则问题会静默蔓延。
