用kafka-go而非sarama做流处理，因其默认支持context.Context、消费位点提交更可控、内存分配更少；sarama需手动管理连接与重试，易因goroutine泄漏或offset提交失败导致重复消费。
为什么用 kafka-go 而不是 sarama 做流处理？
因为 kafka-go 默认支持 context.Context 控制生命周期，消费位点自动提交逻辑更可控，且在高并发读写场景下内存分配更少。而 sarama 的同步 Producer 和 Consumer 需手动管理连接、重试、会话超时等细节，容易在流式场景中因 goroutine 泄漏或 offset 提交失败导致重复消费。
典型踩坑点：
-
sarama.AsyncProducer的错误通道不消费会导致 goroutine 阻塞 -
sarama.ConsumerGroup中Setup/Cleanup方法若含阻塞操作，会卡住整个 rebalance 流程 -
kafka-go的Reader默认按 partition 分配，天然适配流式分片处理；sarama需自行实现 partition-aware 的 worker 调度
kafka-go Reader 如何正确配置才能支撑实时流处理？
关键不在“连得上”，而在“不丢、不乱、不积压”。默认配置只适合低频调试，生产必须调整以下几项：
-
MinBytes设为1（而非默认10240），避免小流量下消息延迟升高 -
MaxWait控制批处理上限，建议设100 * time.Millisecond，平衡吞吐与延迟 -
CommitInterval必须显式设置（如1 * time.Second），否则依赖ReadMessage自动提交，易在 panic 时丢失 offset -
PartitionWatchInterval在动态扩缩容场景下建议设为30 * time.Second，防止频繁 rebalance
示例片段：
立即学习“go语言免费学习笔记（深入）”；
reader := kafka.NewReader(kafka.ReaderConfig{
Brokers: []string{"kafka-01:9092", "kafka-02:9092"},
Topic: "user-events",
GroupID: "stream-processor-v2",
MinBytes: 1,
MaxBytes: 1048576,
MaxWait: 100 * time.Millisecond,
CommitInterval: 1 * time.Second,
PartitionWatchInterval: 30 * time.Second,
})Go 流处理中如何保证 Exactly-Once 语义？
Kafka 本身只提供幂等 Producer + 事务型写入的组合，Go 客户端无法绕过 broker 限制实现端到端 Exactly-Once。实际能落地的是“At-Least-Once + 幂等消费”：
- 启用
EnableIdempotence: true（sarama）或使用kafka-go Writer的RequiredAcks: kafka.RequiredAcksAll - 消费侧必须将业务逻辑与 offset 提交放在同一事务边界内——例如用数据库事务包裹消息处理 + offset 写入 pg/kv 表
- 禁止依赖 Kafka 自动提交（
AutoCommit: true），尤其在流式 pipeline 中有中间状态（如缓存聚合、窗口计算）时 - 若用
kafka-go Reader，务必关闭AutoCommit，改用手动CommitMessages(ctx, msgs...)，并在业务成功后调用
常见误判：把 acks=all 当成 Exactly-Once。它只保证写入不丢，不解决下游重复处理问题。
流式架构里 Topic 分区数和 Go worker 数怎么配？
分区数决定并行度上限，worker 数决定实际并发能力。二者不等时会出现资源浪费或瓶颈：
- 分区数
- 分区数 > worker 数：单个 worker 处理多个 partition，CPU/IO 成瓶颈，且无法利用
kafka-go的 per-partition buffer 优势 - 推荐配比：worker 数 = 分区数 × 1.2（预留 20% 扩容余量），每个 worker 绑定固定 partition（用
ReaderConfig.Partition指定） - 真实生产环境建议分区数 ≥ 12，避免单 partition 成为热点（尤其在 key-based routing 场景）
注意：kafka-go Reader 不支持跨 partition 顺序保证，如果业务强依赖全局顺序（如账户余额变更），必须收拢到单 partition + 单 worker，并接受吞吐量牺牲。
