Redis实现消息幂等的那些事儿，聊聊最靠谱的解决方案和实操经验

综合自多位资深开发者的技术博客、社区讨论及项目实操经验）

今天咱们就来聊聊Redis在实现消息幂等这事儿上,怎么用最靠谱，有哪些坑可以提前避开，所谓消息幂等，说白了就是同一条消息，你让系统处理一次和处理一百次，得到的结果必须是一模一样的，不能因为网络抖动或者消费者重启，导致一条消息被重复消费，最后把账户余额多扣了几遍，或者一个订单生成了好几次，那可就乱套了。

为啥Redis特别适合干这个呢？主要是因为它快，读写都是微秒级别的，而且单线程模型能保证原子性操作，这在判断“这个消息我有没有处理过”的时候，至关重要。

最主流、最靠谱的方案：利用Redis的SETNX命令

这可以说是公认的“金标准”了，SETNX是“SET if Not eXists”的缩写，意思是只有当这个Key不存在的时候，才能设置成功，我们可以把每一条消息都生成一个唯一的标识符（比如消息ID、业务主键加场景标识等）作为Redis的Key。

具体的操作流程是这样的：

1. 当消费者收到一条消息时,先不急着处理业务逻辑。
2. 立刻拿着这个消息的唯一ID作为Key,去Redis里执行一个SETNX操作，可以给这个Key设置一个合理的过期时间（比如半小时），防止数据无限制堆积。
3. 如果SETNX返回1,说明这个Key之前不存在，设置成功了，恭喜你，拿到了“处理权”，可以放心地去执行后续的业务逻辑了，处理完后，这个Key会一直存在，直到过期。
4. 如果SETNX返回0,说明这个Key已经存在了，这意味着什么？意味着这条消息极大概率是之前已经处理过的（可能是ack确认时网络出了问题，导致消息队列又重新投递了），这时候，消费者就应该直接丢弃这条消息，或者打个日志了事，不再进行任何业务操作。

（来源：Redis官方文档以及《Redis设计与实现》一书中对原子性命令的阐述）

这个方法之所以靠谱,就是因为SETNX这个操作是原子的，在分布式环境下，哪怕同时有多个线程或者多个消费者实例收到同一条消息，也只有一个能执行SETNX成功，其他的都会失败，从根本上避免了并发重复处理的问题。

实操中的几个关键点和“坑”

光知道用SETNX还不够,在实际项目中，有几个细节必须处理好，不然照样会掉坑里。

• Key的设计是门艺术：Key绝对不能乱设，最好采用“业务前缀:唯一标识”的模式，比如做支付幂等，可以用 pay_idempotent:order_202405210001，这样既清晰，又方便后期排查问题和做数据统计，唯一标识一定要能精准定位到“同一件需要保证幂等的事”。
• 过期时间一定要设置！ 这是血泪教训，如果你只SETNX，不设置过期时间，那么这个Key就会永远留在Redis里，久而久之，Redis的内存会被这些已经完成历史使命的Key撑爆，设置一个比业务逻辑处理时间长得多的过期时间（比如业务最多处理1分钟，你设30分钟），既能防止重复消费，又能自动清理垃圾。
• 处理成功前Key就过期了怎么办？ 这是个极端但确实可能发生的场景，比如你设置过期时间10秒，但某个消息的业务处理非常复杂，花了15秒，当处理完时，Key已经自动过期了，如果这时候这条消息因为某种原因又被投递过来，SETNX会发现Key不存在，于是又设置成功，导致重复执行。
  • 解决方案参考（来源：某大型电商平台技术分享）：对于这类超长耗时的关键业务，可以考虑不依赖自动过期，而是在业务逻辑完全成功落地数据库后，再手动去设置一个较长的过期时间（或者不设置，但需要有其他清理机制），更复杂的方案可以引入业务状态查询，在SETNX失败后，不去直接丢弃消息，而是去查一下数据库，看这笔业务是不是真的已经做成功了。
• 删除Key的危险操作：有些人可能会想，那我业务处理完后，主动用DEL命令把Key删掉不行吗？非常不推荐！因为这可能引发更诡异的问题，想象一下：业务处理成功 -> 删除Key -> 但此时这条消息还未被确认，恰好消费者崩溃了 -> 消息队列重新投递 -> 因为Key已被删除，SETNX成功 -> 消息被重复处理，依赖自动过期是更安全的选择。

除了SETNX，还有别的招吗？

有,但适用场景不同。

比如Redis的布隆过滤器（Bloom Filter），它是一个空间效率极高的概率型数据结构，能告诉你“某个元素一定不存在”或者“很可能存在”，它特别适合在海量数据中判断是否存在，能节省大量内存。

（来源：Redis Modules官方介绍及多个高并发场景的技术实践案例）

啥时候用它来做幂等呢？当你的消息量巨大无比，并且可以接受极低概率的误判时（比如一些对精确性要求不是百分之百的场景，如重复点击点赞），布隆过滤器的优点是占内存极小，缺点是存在误判的可能，它说“存在”的消息，有微小概率其实是新的消息，会被错误地过滤掉，对于金融、交易等核心场景，SETNX方案依然是首选。

用Redis实现消息幂等,“SETNX + 唯一业务Key + 合理过期时间” 这套组合拳是目前最经过实战检验、最可靠的方案，关键在于理解其原理，并在实际应用中注意Key的设计、过期时间的把控，防范那些边边角角的极端情况，把这些都做到了，你的消息队列基本上就能告别重复消费的烦恼了。