Redis分布式锁能否保证按请求顺序分配？

原生Redis分布式锁无法保证锁的分配顺序 #

不管是基于SETNX的基础分布式锁，还是Redlock算法，本质都是竞争型锁机制——当锁释放后，所有等待的请求会同时向Redis发起抢锁请求，谁的请求先被Redis处理，谁就能拿到锁，完全没有排队逻辑。

回到你的例子：A拿到锁后，B进入等待；之后C发起请求，此时B和C都在等待锁释放。当A释放锁的瞬间，B和C的抢锁请求是并发的，Redis会先处理哪一个完全取决于网络延迟、Redis的命令执行顺序等因素，完全存在C先于B拿到锁的可能，无法保证B的优先级。

实现锁顺序分配的方案：基于Redis有序集合的排队机制 #

要实现“先请求先拿锁”的FIFO顺序，需要在锁之外额外维护一个请求队列，核心思路是用Redis的有序集合（ZSet）来记录请求的顺序，只有队列头部的请求才能尝试获取锁。具体步骤如下：

1. 请求入队：每个请求发起时，生成一个唯一标识（比如UUID），以当前Redis服务器的时间戳作为score，将标识存入ZSet中（确保score递增，对应请求的先后顺序）。
2. 检查队列位置：判断自己的标识是否是ZSet中的第一个元素（通过ZRANGE key 0 0获取头部元素，对比是否一致）。
3. 尝试获取锁：如果是头部元素，就用标准的分布式锁逻辑（比如SET lock_key unique_id NX EX 30）尝试获取锁；如果不是，则监听前一个元素的删除事件（借助Redis的键空间通知），或者以合理间隔轮询检查前一个元素是否已被移除，直到自己成为队列头部。
4. 释放锁并出队：当请求完成业务逻辑后，先删除锁键，再将自己的标识从ZSet中移除，让队列中的下一个请求可以检测到自己成为头部，进而尝试获取锁。

注意事项 #

• 尽量使用Redis服务器的时间戳（通过TIME命令获取）作为ZSet的score，避免客户端时钟不一致导致的顺序错乱。
• 给ZSet中的元素设置过期时间（可以配合Redis的过期键清理），防止某个请求崩溃后一直占据队列位置，导致后续请求无法正常获取锁。
• 轮询间隔不宜过短，避免给Redis造成过大压力；使用键空间通知时，要确保Redis已开启对应配置（notify-keyspace-events Ex）。

内容的提问来源于stack exchange，提问作者Rob Mosher