Kafka消费者在C#中收到重复消息是因默认At-Least-Once语义及自动提交offset导致；需关闭自动提交、手动commit+storeOffsets保证原子性，并结合Redis幂等键或数据库唯一约束实现去重。
为什么 Kafka 消费者在 C# 里总收到重复消息
Kafka 默认提供的是 At-Least-Once 语义，不是“发一次就只消费一次”。只要消费者没来得及提交 offset（比如处理中途崩溃、超时、网络断开），Kafka 就会把那条消息重新投递给其他实例或重启后的自己——这不是 bug，是设计使然。C# 用 Confluent.Kafka 或 Microsoft.Extensions.Hosting.BackgroundService 做消费者时，如果只依赖自动提交（EnableAutoOffsetStore=true），几乎必然遇到重复消费。
C# 手动控制 offset 提交的实操要点
这是最直接、最可控的第一道防线，但必须和业务处理形成原子性闭环：
- 设置
EnableAutoOffsetStore=false和EnableAutoCommit=false，彻底关闭自动行为 - 在消息成功处理完、DB 写入/Redis 更新/外部调用全部完成之后，再调用
consumer.StoreOffsets()+consumer.Commit() - 注意：不要在 try/catch 的 finally 里无条件 commit——失败时 commit 会导致消息丢失；也不要只在 success 分支 commit 而忽略异常后是否该重试的判断
- 若使用
BackgroundService，建议配合using var scope = _serviceProvider.CreateScope();确保 DB 上下文、缓存客户端等生命周期干净，避免跨消息污染
用 Redis + Idempotency-Key 实现幂等去重
这是业务层兜底的核心手段，和 offset 控制正交互补。关键不在“存不存”，而在“怎么存、存多久、怎么查”：
- 消息体里必须带一个稳定、全局唯一的
IdempotencyKey（推荐用Guid.NewGuid().ToString("N")或 Snowflake ID，别用时间戳+随机数拼接） - 用
SET key value EX 3600 NX（即redis.StringSet(key, "1", TimeSpan.FromHours(1), When.NotExists)）做原子写入，返回 true 才执行业务逻辑 - 别用
GET + SET两步操作——中间可能被并发击穿；也别设过长 TTL（如 7 天），否则 Redis 内存压力大且失效策略难对齐业务生命周期 - 如果业务本身有强状态机（如订单从
Pending→Paid），可在去重后加一层WHERE status = 'Pending'条件更新，双重保险
数据库唯一约束是最省心的天然幂等器
很多 C# 开发者一上来就想写缓存、搞分布式锁，其实多数场景下，一张轻量级幂等表就够了：
- 建表只需两个字段：
IdempotencyKey NVARCHAR(64) PRIMARY KEY+CreatedAt DATETIME2 - 插入前不查，直接
INSERT INTO idempotent_log (IdempotencyKey, CreatedAt) VALUES (@key, GETUTCDATE()) - 捕获 SQL Server 的
SqlException.Number == 2627（唯一键冲突）或 PostgreSQL 的23505，直接 return；其他异常才抛出 - 不用定时清理？可以加个
WHERE CreatedAt 的后台任务定期删老数据，不影响主流程
真正难的不是选哪种方案，而是意识到：offset 控制防丢，Redis 防并发，DB 约束防脏写——三者不是替代关系，而是分层防御。漏掉任何一层，在高并发或异常恢复场景下都可能暴露。尤其要注意 C# 中 async/await 和 Kafka offset 提交的异步边界，别让 await ProcessAsync(msg) 和 Commit() 跨越 await 分界线而失去顺序保证。
