Redis消息发送里那些重复信息到底咋整，重复消息问题和处理思路探讨

（引用来源：知乎专栏“架构成长之路”关于消息队列重复消费的讨论） 咱们今天就来聊聊Redis在用来发消息时，一个特别常见又让人头疼的问题：同一条消息，被发了两次，或者被处理了两次，这可咋整？你可能觉得，我这发送端明明只点了一次发送，消费端怎么就收到了两份呢？这里面门道其实不少。

咱们得弄明白,这重复消息到底是从哪儿冒出来的，很多时候，问题不出在Redis本身，而是出在用它的人身上，或者说整个消息流转的环节里。

（引用来源：掘金社区某开发者分享的Redis消息队列实战踩坑记录） 第一种情况，发送端重复发送，想象一下这个场景：你的程序发送了一条消息给Redis，然后它需要等Redis回一个“收到”的信号（比如一个OK响应），但网络这玩意儿有时候会抽风，可能这个“收到”的信号在半路上丢了，或者延迟了很久才到，你的发送程序左等右等等不来回复，心里就毛了：“哎呀，是不是没发成功啊？这可不行，我得再发一次保险点！”得，就这么着，同一条消息就被发了第二遍，Redis可老实了，你发几次它就存几次，它才不管你是不是重复的呢。

第二种情况,消费端惹的祸，这就更常见了，消费端从Redis里（比如通过LPOP命令）拿到一条消息，开始吭哧吭哧地处理，比如要往数据库里插一条记录，处理到一半，程序突然崩溃了！或者服务器重启了，这时候，消息已经从Redis里取出来了（因为LPOP是弹出操作），但业务逻辑根本没走完，等你把程序修好重新启动，它可不知道刚才那条消息处理到哪一步了，它只会继续去Redis里取“下一条”消息，但实际上，刚才那条没处理完的消息，就相当于丢了，业务上没成功，你可能会说，那我不用LPOP这种直接弹出的命令，我用LRANGE之类的只读命令行不行？行是行，但你又得自己维护一个指针记录读到哪儿了，更麻烦，而且容易乱，更棘手的是，有时候消费端处理业务成功了，但是在“告诉Redis这条我处理完了”这个步骤上失败了（比如网络又抖了一下），Redis可能误以为这条消息没被处理，下次还会把它发出来，这也会导致重复消费。

你看,这重复消息的问题，想完全从根源上杜绝，在分布式环境下简直难如登天，网络不可靠、进程会挂掉，这些都是客观存在的，咱们聪明的程序员们就想通了，与其追求一个绝对不重复的“完美”系统（那代价太高了），不如换个思路：咱们就承认消息可能会重复，但要在消费端做好准备，让系统即使收到了重复消息，也不会出错，就像没收到过一样。 这招就叫“幂等性”处理，这个词听着高大上，其实道理很简单。

（引用来源：CSDN博客“分布式系统幂等性设计”） 那具体怎么实现这个“幂等性”呢？这里有几个接地气的思路给你参考：

1. 利用数据库唯一键，这是最常用、也往往最有效的一招，比如你的消息是要给用户发一笔红包，这个操作对应的可能是往数据库里插入一条红包记录，你可以在设计数据库表的时候，给这个表加一个唯一性的约束，比如是“用户ID+活动ID+一个本次请求唯一的流水号”这几个字段组合起来必须唯一，发送消息的时候，把这个流水号也一并带过去，消费端处理时，就是执行一个INSERT操作，如果消息是第一次来，顺利插入；如果因为是重复消息导致流水号重复了，数据库就会报一个唯一键冲突的错误，这时候消费端捕捉到这个错误，直接忽略这条消息，或者给它打个日志，然后正常告诉Redis“处理完了”就行，这样，重复的消息就不会导致数据库里出现脏数据。

2. 自己维护一个“已处理”记录簿，你可以用Redis自己来干这个事！在消费端处理消息之前，先去一个特定的Redis集合（Set）或者一个哈希（Hash）里查一下，这个消息的唯一标识（比如就是上面说的流水号）在不在里面，如果不在，说明是第一次处理，那就正常处理业务，处理完后，把这个标识写到这个集合里，并且可以设置一个过期时间（防止这个记录簿无限变大），如果查的时候发现这个标识已经存在了，那妥妥的就是重复消息，直接跳过，这个方法也很灵活，但要注意，检查记录簿和写入记录簿这两个操作得保证原子性，最好用Redis脚本来实现，避免并发问题。

3. 版本号或者状态机，对于一些更新操作，比如要把订单状态从“已支付”改成“已发货”，你可以在消息里带着一个版本号，或者当前的状态，消费端在处理时，先去数据库查出当前订单的版本号和状态，只有当前状态是“已支付”，并且版本号匹配时，才执行更新操作，同时把版本号加1，如果重复消息来了，订单状态可能已经是“已发货”了，版本号也对不上，更新自然就不会执行。

用Redis做消息队列,心里一定要有根弦：重复消息是大概率会发生的常态，我们的核心应对策略不是在发送环节堵死它（很难堵干净），而是在最终的消费环节做好幂等性设计，让系统变得“健壮”，能够自动消化掉这些重复信息，保证业务的正确性，这样，即便网络波动、服务重启，数据也能保持一致，这才是解决问题的根本之道。