Redis消息队列里怎么搞加锁，细节和思路聊聊，避免冲突问题

在Redis消息队列里搞加锁，核心目的就是为了解决一个老问题：防止多个消费者同时处理同一条消息，想象一下，你有一个订单处理的队列，一个订单号只能被减一次库存，如果两个工作人员（消费者）同时看到这个订单并都去处理，那库存不就乱套了吗？我们需要一种机制，让一个消息被一个消费者“占住”，其他消费者看到它已经被占用了，就自动跳过,去处理别的消息。

最常用、也最直接的方法就是利用Redis一个叫做SETNX的命令，这个命令的名字是“SET if Not eXists”的缩写，意思是“如果不存在才设置”，它非常适合用来实现一个简单的锁，它的工作方式是：我尝试用SETNX命令往Redis里设置一个键值对，如果这个键之前不存在，Redis就设置成功，并返回1给我，表示我成功拿到了锁；如果这个键已经存在，Redis就什么都不做，返回0给我,表示锁已经被别人拿走了。

具体到消息队列里怎么用呢？思路是这样的：

1. 设计锁的钥匙（Key）：这个非常关键，锁的Key不能随便起，它必须和你要锁定的资源紧密相关，在处理消息队列时，最好的钥匙往往就是消息本身唯一的标识符，消息体里包含一个订单号“order_12345”，那么锁的Key就可以设计成 lock:order:order_12345，这样，不同的消息有不同的锁，互不干扰；而同一条消息，因为Key相同,所有消费者都会来争抢同一把锁。

2. 消费者处理消息的步骤：

   • 第一步：尝试加锁。 消费者从队列里拿到一条消息后，先不急着处理，它立刻使用SETNX命令，以消息唯一ID构成的Key（lock:order:order_12345）去Redis里设置一个值，值是什么不重要，可以简单设为“1”或者“locked”，非常重要的一步是，给这个Key设置一个过期时间（TTL），比如10秒，这是为了防止某个消费者崩溃了，锁永远不释放，导致消息“卡死”在队列里，设置过期时间是我们的“安全绳”。
   • 第二步：检查加锁结果。
     • 如果SETNX返回成功（返回1），恭喜你，你抢到锁了！现在你可以放心地去处理这条消息了，比如扣减库存、发送邮件等，处理完成后，理论上应该主动删除（DEL）这个Key来释放锁，好让其他资源可用，但因为有过期时间，即使你忘了删，锁也会在10秒后自动释放,不会造成永久堵塞。
     • 如果SETNX返回失败（返回0），说明这把锁已经被其他消费者抢先拿走了，这时候你该怎么办？你不能傻等着，因为队列可能还有很多其他消息等着处理，正确的做法是立即放弃处理这条消息，注意，这里不是把消息从队列里删除，而是让你（这个消费者）放手，因为消息队列（比如LPOP）可能已经把它弹出来了，或者像BRPOPLPUSH这样的命令已经把它挪到另一个“处理中”的列表了，你放手后，这条消息会以某种形式留在系统里，等待那个拿到锁的消费者去处理，或者，在一些队列模式下，你可以选择把消息重新放回队列尾部,让它稍后再被尝试。

3. 处理时间比锁过期时间长怎么办？ 这是一个经典的边界问题，假设你的业务处理需要15秒，但锁只设置了10秒过期，可能发生的情况是：你还在吭哧吭哧处理，第10秒的时候锁自动失效了，另一个消费者看到锁没了，以为没人处理，于是它抢到锁也开始处理同一条消息,这就又回到冲突的原点了。

   • 解决思路：要么你合理评估最长的处理时间，把锁的过期时间设得足够长（比如30秒），确保正常情况下的处理都能在锁期内完成，要么，你可以实现一个“锁续期”的机制，就是说，你拿到锁之后，另起一个后台线程，每隔一段时间（比如锁过期时间的三分之一，也就是3秒）就去检查一下锁是否还在，如果在，就重新把它的过期时间设置为10秒，这样，只要你这个消费者还“活着”，锁就会一直持有，直到你处理完主动释放它，这个机制稍微复杂一点,但更健壮。

4. 有没有更简单的现成方案？ 有，Redis官方从2.6版本开始，给SET命令增加了一个参数组合，可以直接实现SETNX和设置过期时间的原子操作，命令是 SET key value NX PX 10000，用这个命令比先SETNX再EXPIRE要好，因为它是原子性的，避免了刚SETNX成功还没来得及设置EXPIRE进程就挂掉,导致死锁的极端情况。

在Redis消息队列里加锁，避免冲突的核心思路就是：一抢（用消息ID做Key尝试SETNX）、二判（成功才处理，失败就放弃）、三设防（一定要设置过期时间，防止死锁），这个方法简单有效，能解决绝大部分场景下的并发冲突问题，如果业务特别复杂，对一致性要求极高，可能需要考虑更重的分布式锁方案，但对于普通的队列任务,这个思路已经完全够用了。