Redis分布式锁实现：从SETNX到Redlock演进

可视化演示

动态演示Redis分布式锁实现的核心机制，通过源头/管道/节点/终端四种模式展示关键概念与交互流程。

锁的基础概念

游泳馆的更衣室里，储物柜的管理员立了一条铁规矩：任何一个储物柜，同一时刻只允许一个人使用。这就是“互斥”——你锁上柜门的时候，别人不可能再往里面塞东西。计算机世界里，多个进程同时修改同一份数据时，也需要这样一条铁规矩，否则就会出现“两个人同时把衣服塞进同一个柜子”的混乱局面。

“互斥”在单机时代很容易实现：一个内存标志位、一把操作系统锁就够了。但在分布式系统中，进程跑在不同的机器上，没有共享内存，这时候就需要一个所有进程都能访问的“中间人”来裁决——Redis 就是这样的中间人。它维护一把“虚拟锁”：锁存在时，其他进程必须等待；锁不存在时，第一个来的人可以获取它。

用数学语言描述互斥，最核心的判断只有一个：同一时刻最多只有一个进程持有锁。

回到比喻里：互斥是储物柜的铁规矩，但光有规矩还不够。如果一个人拿了钥匙却猝不及防地消失了，柜门永远打不开——这就是死锁。所以真正可靠的分布式锁，既要保证互斥，还要保证“意外发生时锁能自动解开”，这也是后续所有演进的需求来源。

SETNX初代锁

最早的 Redis 分布式锁非常朴素：储物柜管理员手里有一个登记本，上面写着“当前被占用的柜号”。顾客来存东西时，管理员先翻一眼登记本——如果柜号没被登记，就把名字写上去，把钥匙交给顾客；如果已经被登记，就摇摇头说“换一个吧”。这个“翻一眼、写一笔”的动作，在 Redis 里对应一条天然原子的命令：SETNX（SET if Not eXists，不存在才设置）。

SETNX 的本质是“只有键不存在时才能写入”。这恰恰是“先查再占”的安全版：它把“检查柜子有没有被占”和“写登记本”两个动作合并成一步，中间不会插入其他顾客。完整语义可以写成下面的分段函数：

初代锁的用法很直接：抢锁就是 SETNX lock_key owner_id，释放锁就是 DEL lock_key。在游泳馆里，这相当于“登记本上写名字”对应挂锁，“划掉名字”对应开锁。可是问题很快暴露了：如果顾客拿着钥匙突然晕倒在泳池边，登记本上的名字永远不会被划掉，那把锁也永远打不开。SETNX 不是原子操作的一部分吗？确实，但原子性救不了“忘记释放”的人为失误——进程崩溃了，DEL 命令永远不会执行。这就是初代锁最经典也最致命的缺陷：没有过期时间，死锁风险极高。

超时与过期

为了解决“人消失、锁还在”的问题，储物柜管理员想出一个新办法：每把锁都装一个倒计时器。顾客挂锁时设定一个时间，比如 10 分钟；10 分钟后不管人有没有回来，锁自动弹开。这样即使顾客晕倒、跑路、彻底失联，柜子也一定能被重新使用。这个“倒计时器”对应 Redis 键的 过期时间（TTL）。

在 Redis 里，加锁从“先 SETNX 再单独 EXPIRE”演变为一条命令完成：SET lock_key owner_id NX EX 10。其中 NX 保证“只有键不存在时才设置”，EX 10 保证“锁在 10 秒后自动过期”。为什么不能用两个独立的命令？因为“加锁”和“设过期”若分开执行，中间进程一旦崩溃，锁照样没有过期时间，死锁问题依旧。合并成一条原子命令，删除了这个致命的“空窗期”。

锁的剩余存活时间，就是一个简单的减法：

有了过期时间，死锁问题迎刃而解，但新的矛盾又浮出水面：TTL 设多长合适？设太短，业务还没执行完锁就自动弹开了，别人会闯进来抢资源；设太长，一旦进程崩溃，其他进程要等待很久才能拿到锁。更麻烦的是，锁可能到了“该释放”的时候，而持锁人业务还没做完——柜门“咔哒”一声弹开，另一个顾客立刻把东西塞了进去。那时候原来的顾客回来，迷迷糊糊地以为柜子还是自己的，伸手就去开锁——他会打开谁的门？

防误删优化

想象一个更具体的场景：顾客 A 锁了 5 分钟的柜子，结果超时锁自动弹开；顾客 B 正好过来，锁上了同一个柜子。这时 A 回来了，他伸手用钥匙一拧——柜门开了，里面是 B 的衣物！A 一脸懵地把 B 的东西取走了。问题出在哪？A 的钥匙（锁值）没有标识主人身份，任何一把“通用钥匙”都能打开这把锁。

在 Redis 锁里，这个问题的根源是：释放锁时直接 DEL lock_key，完全不检查这个锁是不是当前进程加的。解决方案是给每把锁配一把“专属钥匙”——加锁时存入一个唯一标识（通常是 UUID），释放前先取出锁的值与自己的标识对比，一致才允许删除：

但“先 GET 再 DEL”存在一个新的安全隐患：从 GET 到 DEL 之间，锁可能刚好过期，另一个进程抢到了锁，这时再去 DEL 就会把别人的锁误删。要根治，必须把“比较”和“删除”合并成一个不可拆分的原子操作。Redis 原生支持 Lua 脚本，脚本内的多条命令在单线程中连续执行，中间不会插入任何其他命令——这个概念相当于管理员把“验钥匙、开柜门”设计成一个机械联动装置：钥匙插进去的一瞬间，验证和开锁同步完成，中间没有停顿，别人插不进来。

有了这个防误删的升级，Redis 锁在“释放安全”上才算是完备了。但故事还没结束：A 在业务逻辑里写了一个递归函数，外层调用了加锁的方法，内层又调用了同一个加锁方法——同一个进程想重复获取同一把锁，却被自己挡在了门外，这就引出了下一个问题：锁能不能被同一个持有者多次获取？

可重入设计

游泳馆里还有一种尴尬的场景：顾客 A 锁好柜子后，忽然想起外套还在泳池边，于是拿了钥匙去取，回来发现钥匙落在储物柜里了——他不得不再找管理员“再开一次”。有些高级储物柜支持“同一把钥匙可以多次打开同一把锁”，只要第一次锁上后，钥匙的主人不换人，再开门、再锁上都不会抵触。计算机里的可重入锁就是这个意思：同一个线程可以多次获取同一把锁，而不会阻塞自己。

为什么需要可重入？因为业务代码常常层层嵌套：方法 A 加锁，A 内部调用方法 B，B 又加同一把锁；如果锁不可重入，B 就会被自己挡在外面，直接死锁。解决方案是给锁加一个计数器：第一次获取时计数器从 0 变 1；同一个线程再次获取时，计数器继续加一；每次释放时减一，只有减到 0 才真正删除锁键：

在 Redis 中实现可重入锁通常有两种方式：一是将计数器和 owner 存在一个 Hash 结构里，用 HINCRBY 做自增操作；二是在应用层用线程本地变量维护计数器，只有首次加锁和最后一次释放才真正操作 Redis。无论哪种方式，核心都是“计数器归零才释放”。可重入设计解决了“自己拦自己”的问题，但到目前为止，我们讨论的仍然是单节点 Redis 上的锁——如果这台 Redis 宕机了，整个储物柜体系就瘫痪了。要不要给储物柜做“多区域备份”？

Redlock算法

单节点的 Redis 锁有一个致命软肋：Redis 如果挂了，锁就全丢了；即使有主从架构，主节点故障时从节点尚未同步锁数据，也会导致“旧锁丢失、新锁产生”的竞态。就像你只有一间更衣室，屋顶漏水或者管理员请假，系统就崩溃。为了提升可用性，Redis 官方提出了 Redlock 算法——在多台独立部署的 Redis 实例上同时加锁，只有超过半数的实例都同意，才真正算拿到锁。

Redlock 的思路非常像“多个独立投票区”：假设有 5 间互不相通的更衣室（5 个 Redis 实例），顾客要存东西时，必须同时去 5 间更衣室挂锁，每间都挂锁成功打了勾。如果 5 间中有 3 间以上成功，那么即使某个更衣室的管理员撒谎或睡觉，剩下的柜子仍然能保证互斥。这个“过半数”的判定，在数学上就是多数派原则：

具体流程是：客户端先记录当前时间 t1，然后依次向 N 个 Redis 实例发送 SET key value NX EX ttl 命令（带很短的响应超时，比如 50ms），加完所有实例后记录 t2，Δt = t2 - t1。如果 N_ok ≥ ⌊N/2⌋+1 且 Δt < TTL，就把锁的有效时间定为 TTL - Δt。失败时，需要向所有实例发送释放锁命令——包括那些没加成功的实例，防止“部分成功”残留垃圾锁。

Redlock 用多数派换来了高可用，但它并非完美无瑕。它的主要争议点在于时钟漂移：如果某个实例的服务器时钟跳变，锁的过期时间计算就会出错。比如一台 Redis 的时钟突然往后拨了几分钟，它认为锁还有效，但实际早就过期了，另一个客户端就能趁机拿到锁。此外，Redlock 假设各实例之间完全独立，但在实际部署中，多个 Redis 可能运行在同一批物理机上，一旦宿主机宕机，多数派也会同时失效。因此 Redlock 适用于“需要更高可用性”的场景，但不能视为绝对安全的银弹。回到比喻中：多间更衣室确实让“管理员偷懒”的风险大大降低，但如果在同一座楼上，一场火灾就能烧掉全部更衣室——真实世界的工程抉择，永远是平衡的艺术。

AI 应用场景

Python 演示

import timeimport uuidimport redis  class SimpleLock:    """基础版 Redis 分布式锁：SETNX + EXPIRE + Lua 防误删"""    def __init__(self, client, key, ttl=10):        self.client = client        self.key = key        self.ttl = ttl        self.owner = str(uuid.uuid4())     def acquire(self):        # SET key value NX EX ttl：原子完成加锁与过期设置        return bool(self.client.set(            self.key, self.owner, nx=True, ex=self.ttl        ))     def release(self):        # Lua 脚本：先校验持有者，再删除，保证原子性        lua = """        if redis.call('get', KEYS[1]) == ARGV[1] then            return redis.call('del', KEYS[1])        else            return 0        end        """        ok = self.client.eval(lua, 1, self.key, self.owner)        return bool(ok)  class ReentrantLock(SimpleLock):    """可重入版：加计数器，同一线程可多次获取锁"""    def __init__(self, client, key, ttl=10):        super().__init__(client, key, ttl)        self.count = 0     def acquire(self):        cur = self.client.get(self.key)        if cur is None or cur.decode() == self.owner:            self.client.set(self.key, self.owner, ex=self.ttl)            self.count += 1            return True        return False     def release(self):        if self.count <= 0:            return False        self.count -= 1        if self.count == 0:            return super().release()        self.client.expire(self.key, self.ttl)        return True  if __name__ == '__main__':    client = redis.Redis(host='127.0.0.1', port=6379, db=0)    lock = ReentrantLock(client, 'order:lock', ttl=5)    if lock.acquire():        print('获取锁成功，执行临界区操作...')        if lock.acquire():            print('再次获取锁成功（可重入）')        print('释放锁：', lock.release())        print('释放锁：', lock.release())

1. return bool(self.client.set(self.key, self.owner, nx=True, ex=self.ttl))SET 命令的 NX 和 EX 选项把“加锁”和“设过期”合并成一步原子操作，避免死锁。
2. ok = self.client.eval(lua, 1, self.key, self.owner)把 Lua 脚本整体发给 Redis 执行，Redis 单线程特性保证比较与删除之间不会有其他命令插入。
3. if redis.call('get', KEYS[1]) == ARGV[1] thenLua 脚本中先读取锁值，和当前线程的 owner 标识比对，只有相等才继续删除。
4. cur = self.client.get(self.key); if cur is None or cur.decode() == self.owner可重入判断：锁不存在或锁值属于自己时才允许加锁。
5. self.count += 1可重入锁的计数器加一，记录同一线程获取锁的次数。
6. self.client.expire(self.key, self.ttl)每次释放时刷新过期时间，防止业务未完成锁就自动过期。

常见误区

面试题