关键在于“不丢、不乱、不积压”，需选用kafka-go客户端，显式配置CommitInterval、MinBytes、MaxWait等参数，手动控制offset提交并结合数据库事务保障At-Least-Once，用带缓冲channel限流并发goroutine。
Go语言集成Kafka实现高并发消息处理，关键不在“连得上”，而在“不丢、不乱、不积压”。核心是选对客户端、控好并发粒度、管住偏移量提交时机。
优先用 kafka-go，而非 sarama
sarama 需手动管理连接生命周期、重试逻辑和 offset 提交，容易因 goroutine 泄漏或提交失败引发重复消费；kafka-go 基于 context 控制读取生命周期，Reader 默认按 partition 分配，天然适配流式分片，内存占用更低，更适合长期运行的高并发消费者服务。
- 避免 sarama.AsyncProducer 的错误通道不消费导致 goroutine 阻塞
- 禁用 sarama.ConsumerGroup 中 Setup/Cleanup 的阻塞操作，否则会卡死 rebalance
- kafka-go Reader 的 CommitInterval 必须显式设置（如 1 秒），否则 panic 时可能丢失 offset
配置 Reader 支撑实时流处理
默认配置只适合调试。生产环境需针对性调整：
- MinBytes 设为 1：避免小流量下因等待凑够 10KB 而引入毫秒级延迟
- MaxWait 设为 100ms：平衡吞吐与端到端延迟
- CommitInterval 显式设为 1s：确保 offset 定期持久化，且不依赖 ReadMessage 自动提交
- PartitionWatchInterval 设为 30s：防止集群动态扩缩容时频繁触发 rebalance
手动控制 offset 提交，保障 At-Least-Once
不要依赖 Kafka 自动提交。高并发场景中，业务逻辑常含中间状态（如缓存聚合、窗口计算），自动提交会导致状态与 offset 不一致。
立即学习“go语言免费学习笔记（深入）”；
- 使用 FetchMessage 替代 ReadMessage，获取消息后自行决定何时提交
- 将业务处理与 offset 写入数据库（如 PostgreSQL）放在同一事务中，实现“处理成功 → offset 持久化”原子性
- 启用幂等写入（如 kafka-go Writer 设置 RequiredAcks: kafka.RequiredAcksAll），配合服务端幂等 Producer
用带缓冲 channel 控制 Goroutine 并发数
每条消息起一个 goroutine 看似简单，但无限制会耗尽系统资源。应引入信号量机制：
- 声明 semaphore := make(chan struct{}, N)，N 为最大并发数（如 50）
- 每次启动 goroutine 前先 semaphore <- struct{}{}，处理完再
- 配合 sync.WaitGroup 等待全部完成，避免进程提前退出
- 对失败消息实现有限重试（如最多 3 次），超限则转入死信队列
