选sarama因其生产环境更友好，支持自动重试、分区重平衡、消费者组协调和可配置Offset自动提交；kafka-go轻量但默认不处理断连重连，易丢消息。
为什么用 sarama 而不是 kafka-go？
Go 生态里主流 Kafka 客户端就两个：sarama 和 kafka-go。选 sarama 的核心原因是它对生产环境更友好——支持自动重试、分区重平衡、消费者组协调、Offset 自动提交（可配）；kafka-go 更轻量，但默认不处理网络断连后的重连逻辑，容易在微服务滚动更新或网络抖动时丢消息。
如果你的微服务要跑在 Kubernetes 里、需要高可用消费、且不希望自己手写 Offset 管理和心跳保活，sarama 是更稳妥的选择。不过它依赖 golang.org/x/net，某些代理环境下 go mod tidy 可能失败，得加 replace 或换镜像源。
怎么初始化一个带重试和超时的 sarama.SyncProducer？
同步生产者适合关键业务消息（比如订单创建后发通知），要求调用方明确知道成功或失败。但默认配置下，sarama.NewSyncProducer 会卡死在连接失败或 broker 不可用时，必须手动设超时和重试。
-
config.Producer.RequiredAcks = sarama.WaitForAll：确保所有 ISR 副本都写入才返回，避免单点故障丢数据 -
config.Producer.Retry.Max = 3：重试上限，配合config.Net.DialTimeout和config.Net.ReadTimeout（建议都设为10s） -
config.Metadata.Retry.Max = 3：防止首次获取 topic 元数据失败导致初始化卡住 - 别漏掉
config.Net.SASL.Enable = true（如果集群启用了 SASL/PLAIN 或 SCRAM）
示例片段：
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
config := sarama.NewConfig()
config.Producer.RequiredAcks = sarama.WaitForAll
config.Producer.Retry.Max = 3
config.Net.DialTimeout = 10 * time.Second
config.Net.ReadTimeout = 10 * time.Second
config.Net.WriteTimeout = 10 * time.Second
producer, err := sarama.NewSyncProducer([]string{"kafka:9092"}, config)
消费者组怎么避免重复消费和消息堆积？
用 sarama.NewConsumerGroup 启动消费者组时，重复消费和堆积往往不是 Kafka 本身的问题，而是你的代码没处理好 Offset 提交时机和心跳间隔。
- 把
config.Consumer.Group.Session.Timeout设为30s，同时config.Consumer.Group.Heartbeat.Interval设为3s：太长的心跳间隔会导致 rebalance 频繁，太短则增加 broker 负担 - 务必在业务逻辑处理完成后再调用
session.Commit()，不要在 goroutine 里异步提交——否则可能提交了未处理成功的 offset - 如果单条消息处理耗时超过
session.Context().Done()触发时间（即 session 超时），Kafka 会主动踢出该 consumer，导致重复分配分区。这时要在处理前检查ctx.Err()并提前退出 - 监控
kafka_consumergroup_lag指标，滞后超过 1000 条就得查是不是 handler 里有阻塞 IO 或 panic 未 recover
微服务重启时如何保证 Offset 不丢、不重？
这个问题本质是「Exactly-Once」的简化实现。Kafka 0.11+ 原生支持事务，但 Go 客户端目前只有 sarama 实验性支持 TransactionalID，线上慎用。更现实的做法是靠应用层控制：
- 消费者启动时，先从 Kafka 加载当前 group 最新 committed offset（
sarama.OffsetOldest或sarama.OffsetNewest不够用） - 用外部存储（如 Redis 或数据库）记录每个 partition 最近一次成功处理的 offset，重启后比对并跳过已处理消息——但这要求消息体带唯一 ID，且业务幂等
- 最常用也最省事的方式：关闭自动提交（
config.Consumer.Group.AutoCommit.Enable = false），只在 handler 成功执行后显式session.MarkOffset()，并在 defer 里调用session.Commit()
注意：MarkOffset 只是内存标记，真正落盘靠 Commit；如果服务 crash 在 MarkOffset 之后、Commit 之前，下次启动会从上次成功 commit 的位置开始，多消费几条——所以 handler 必须幂等。
