kafka消费者天然不幂等，因at-least-once语义及rebalance、崩溃等导致重复消费；enable.idempotence仅作用于生产者；redis setnx是可靠前置校验方案，需原子操作、带业务上下文的key、合理过期时间，并避免依赖db唯一约束。
为什么 Kafka 消费者天然不幂等
Kafka 的 at-least-once 语义决定了重复消费是常态，不是异常。消费者崩溃、网络超时、rebalance 触发时 offset 回滚、手动重置 offset —— 这些都会导致同一条消息被拉取多次。而 enable.idempotence=true 只作用于生产者端，且仅保障单会话、单分区内的写入不重复；它对消费者完全无效，也完全不感知业务逻辑。
用 Redis SETNX 做前置校验是最简可靠方案
核心动作必须是原子的：消费前查、存、处理三步合一。推荐用 SET key value EX 3600 NX，而不是 GET + SET 两步 —— 中间可能被其他 goroutine 插入，破坏幂等性。
-
key必须带业务上下文，例如"idempotent:order_created:20260526-ABC789"，不能只用 rawmessage_id（不同 topic 或 producer 可能撞 ID） -
EX时间要大于单次业务处理最大耗时，建议设为超时时间的 2–3 倍。比如业务处理最长 15s，这里设EX 45 - 若
SetNX返回false（即 key 已存在），应直接return nil，不 panic、不重试、不提交 offset —— 否则会触发 Sarama 的自动重试或框架级重投 - 业务逻辑必须在
SetNX成功后才执行；若业务 panic，靠 defer 清理 key 不可靠，更推荐让业务本身可重入（如扣款前先查余额是否足够）
别把数据库唯一约束当幂等依据
有人图省事，在 INSERT INTO orders (id, ...) 上加主键或唯一索引，靠 DB 报错来拦截重复。这不可靠：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- DB 报错是终态反馈，不是前置判断；错误发生时，业务逻辑可能已执行一半（如发了通知、调了外部接口）
- 高并发下唯一约束冲突可能引发锁等待甚至死锁，拖慢整体吞吐
- 某些场景（如分库分表）唯一索引无法跨物理库保证，约束失效
数据库约束适合兜底，不能替代前置幂等校验。
并发消费同一条消息时的正确响应方式
多个 goroutine 同时拿到同一条消息（比如多 partition 多 consumer 实例，或同一消息被 rebalance 后重复分配），SETNX 会自然让只有一个成功。关键是怎么收尾：
- 成功者继续执行业务逻辑，完成后提交 offset
- 失败者必须明确跳过：log 记录
"duplicate message skipped"，然后return nil - 绝对不要返回 error —— Sarama 默认会重试该消息，Redis PubSub 客户端也可能重发，反而放大问题
- offset 提交时机必须和幂等校验强绑定：只有
SetNX成功 + 业务执行完成，才提交；否则不提交，让 Kafka 下次再推（但下次仍会被幂等拦截）
真正的难点不在代码怎么写，而在 key 的设计粒度和生命周期管理：太粗（如全用 topic 名）漏判，太细（如带上毫秒时间戳）导致误判；过期时间设短了清理太快，设长了占内存。这些得贴着你的业务 SLA 和数据规模反复调。
