当前位置：首页 > news >正文

Redis分布式锁实战：从原理到高可用架构设计

news 2026/8/26 4:03:56

1. 从一次线上事故说起：为什么我们需要分布式锁

那天晚上十一点，我正打算关电脑，突然收到一连串的告警短信。核心业务线的订单系统出现了大量“超卖”现象——一个热门商品，库存明明只剩100件，却卖出了150多单。技术群里瞬间炸开了锅，DBA排查数据库没有死锁，应用日志显示多个服务实例都在“同时”扣减库存，并且都成功了。问题根源很快被定位：我们那个运行了两年多的“乐观锁”机制，在瞬时高并发下彻底失效了。代码里那个经典的update stock set count = count - 1 where id = ? and count > 0，在多个服务实例、多个数据库连接同时执行的瞬间，读取到的库存值可能都是100，然后都成功扣减了1，最终导致库存被扣成了负数。

这次事故让我彻底明白，在分布式系统架构下，尤其是当你的服务从单体应用拆分成多个独立部署的实例后，传统的、基于单进程多线程的锁机制（比如Java里的synchronized或ReentrantLock）已经完全失去了作用。这些锁只能管住自己JVM进程内的线程，管不了另一台服务器上另一个JVM进程里的请求。于是，“分布式锁”成为了我们必须引入的基础设施。它的核心目标很简单，却又至关重要：在分布式部署的多台机器、多个进程之间，实现互斥访问，确保在同一时间，只有一个客户端能执行某段关键代码或访问某个共享资源，比如扣减库存、生成全局唯一ID、防止重复提交等场景。

而在众多实现分布式锁的技术选型中，Redis因其高性能、丰富的数据结构和相对简单的模型，成为了最流行、最快速上手的选择。它不像ZooKeeper那样强一致但写性能稍弱，也不像基于数据库的方案那样笨重。用Redis实现分布式锁，核心思路是利用其SETNX（SET if Not eXists）命令的原子性：只有一个客户端能成功设置某个键，谁先设上，谁就拿到了锁。听起来很简单，对吧？但魔鬼藏在细节里。一个在生产环境能扛住高并发、网络抖动、服务宕机的健壮分布式锁，远不止一个SETNX命令那么简单。接下来，我就结合自己踩过的坑和最佳实践，拆解用Redis实现一个工业级分布式锁需要闯过的重重关卡。

2. 从SETNX到SET：分布式锁的原子性基石

最初级的Redis分布式锁实现，大概长这样：

SETNX lock_key unique_value

如果返回1，表示加锁成功，执行完业务后，再执行DEL lock_key释放锁。这个方案有两大致命缺陷：第一，如果客户端加锁后宕机，这个锁就永远无法释放，成了“死锁”；第二，释放锁时直接DEL，可能误删其他客户端持有的锁（比如客户端A阻塞导致锁超时释放，客户端B获得锁，此时A恢复继续执行，就会删除B的锁）。

为了解决死锁问题，我们引入了过期时间。但注意，下面这个操作是错误的：

SETNX lock_key unique_value EXPIRE lock_key 10

因为SETNX和EXPIRE是两个独立的命令，不具备原子性。如果在执行完SETNX后、执行EXPIRE前客户端崩溃，锁依然没有过期时间。所以，Redis 2.6.12之后，我们必须使用原子性的SET命令配合NX和PX选项：

SET lock_key unique_value NX PX 10000

这条命令的意思是：当键lock_key不存在时(NX)，设置其值为unique_value，同时设置过期时间为10000毫秒(PX)。这是一个原子操作，要么一起成功，要么一起失败，完美解决了锁的自动释放问题。

这里的unique_value必须是一个全局唯一的标识，通常可以用UUID + 线程ID，或者更简单的UUID。它的核心作用是实现锁的持有者校验，确保只有锁的持有者才能释放锁。释放锁的逻辑不再是简单的DEL，而是一个Lua脚本：

if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("del", KEYS[1]) else return 0 end

这个脚本保证了“获取锁的值”和“删除锁”这两个操作在Redis服务器端的原子性执行。即使客户端在GET之后、DEL之前发生了网络延迟或阻塞，也不会出现误删，因为判断和删除在Redis单线程模型中是不可分割的。

注意：unique_value的生成必须确保在分布式环境下的唯一性。我曾见过有团队使用“IP地址+进程ID+线程ID”的组合，在容器化部署（IP可能变动）或线程复用场景下，这可能会带来风险。使用标准的UUID.randomUUID().toString()是更稳妥的选择。

3. 锁的续期与看门狗：应对长耗时业务的挑战

设置了过期时间（比如10秒），解决了死锁，但引入了新问题：如果业务逻辑的执行时间超过了锁的过期时间怎么办？例如，一个复杂的数据库事务或者一个外部RPC调用耗时15秒，但锁10秒就自动释放了。此时，其他客户端就能获取到锁，导致两段业务代码同时进入临界区，数据一致性被破坏。

这就是分布式锁领域经典的“锁提前释放”问题。解决方案是：锁续期，也称为“看门狗”(Watchdog)机制。其原理是，在加锁成功后，启动一个后台守护线程，定期（比如在过期时间的三分之一时，即第3秒）去检查锁是否还被当前客户端持有，如果是，则自动对锁的过期时间进行续期（例如，重新设置为10秒）。

这个逻辑同样需要用Lua脚本来保证原子性（检查+续期）：

if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("pexpire", KEYS[1], ARGV[2]) else return 0 end

自己实现一个健壮的看门狗机制并不简单，需要考虑线程池管理、续期失败的重试、客户端优雅关闭时如何停止续期等。因此，在实际生产中，我强烈建议直接使用成熟的客户端库，比如Redisson。Redisson内置了完善的看门狗机制，默认情况下，它加的锁如果没有指定leaseTime，就会启动看门狗，每隔lockWatchdogTimeout/ 3 的时间（默认30秒/3=10秒）去续期，将锁的超时时间重置为lockWatchdogTimeout（默认30秒）。这大大简化了我们的工作。

实操心得：对于明确知道执行时间的短任务，建议在加锁时直接指定一个合理的leaseTime（租约时间），并禁用看门狗。这样可以避免不必要的续期开销。例如，一个简单的库存查询和扣减，通常能在100毫秒内完成，那么设置一个3秒的锁过期时间就足够了。Redisson中可以通过lock.lock(3, TimeUnit.SECONDS)来指定，这样就不会启动看门狗线程。

4. 可重入性：让同一个线程能再次进入锁

什么是可重入锁？简单说，就是同一个线程在外层方法获取锁之后，在进入内层方法时会自动获取锁。在单机JVM中，ReentrantLock和synchronized都是可重入的。在分布式锁中，我们也需要这个特性。

考虑这个场景：你在一个加锁的方法methodA()里，调用了另一个也需要相同锁的methodB()。如果锁不可重入，那么线程在methodB()中尝试获取锁时就会发生死锁——它在等待一个自己已经持有的、但永远不会释放的锁。

实现可重入锁，需要在Redis中存储更多的信息。不能只存一个客户端标识，还需要存储一个重入计数器。常见的结构是使用Redis的Hash：

Key:lock_key
Field:unique_client_id(如8743c9c0-0795-4907-87fd-6c719a6b4586:1)
Value:重入次数

加锁时（Lua脚本）：

判断lock_key这个Hash是否存在。
如果不存在，或存在的字段就是当前客户端ID，则将对应字段的值加1，并设置过期时间。
如果存在且字段是其他客户端ID，则获取锁失败。

解锁时（Lua脚本）：

判断lock_key这个Hash中，指定客户端ID字段的值。
如果值大于1，则减1。
如果值等于1，则删除整个Key。

同样，这部分逻辑非常复杂，自己实现容易出错。Redisson的RLock对象天然就是可重入的，它内部使用Hash结构维护了重入次数，我们无需关心底层实现，直接像使用ReentrantLock一样使用即可。

5. 集群环境与RedLock：当主从切换遇上锁失效

前面讨论的都是基于单个Redis实例（或代理模式下的Sentinel/Cluster）。在Redis主从架构下，会有一个新的致命问题：主从异步复制导致的数据丢失。

流程是这样的：

客户端A在Master节点上成功加锁（设置了一个Key）。
在Master将这把锁同步到Slave节点之前，Master宕机了。
Sentinel/Cluster触发故障转移，其中一个Slave被提升为新的Master。
此时，新的Master上没有客户端A刚才加的那把锁！
客户端B向新的Master申请同一把锁，会成功。于是，客户端A和客户端B同时持有了同一把锁，系统的一致性被破坏。

这就是著名的“主从切换锁失效”问题。为了解决这个问题，Redis的作者Antirez提出了RedLock（红锁）算法。它的核心思想是不再依赖单个Redis实例，而是同时向多个（通常为5个）独立的Redis主节点申请锁，并且这些主节点之间没有主从复制关系，是完全孤立的，以避免同时宕机。

RedLock算法流程如下：

获取当前时间（以毫秒为单位）。
依次尝试向N个Redis实例（如5个）执行加锁命令（SET key random_value NX PX timeout）。这里设置一个远小于锁自动释放时间的网络超时时间（例如5-50ms），避免长时间阻塞。
客户端计算获取锁总共消耗的时间（当前时间 - 步骤1的时间），并且只有当客户端在大多数（N/2 + 1）实例上成功获取锁，且总耗时小于锁的有效时间，锁才算是获取成功。
如果获取锁成功，锁的真正有效时间等于初始有效时间减去获取锁的总耗时。
如果获取锁失败（要么没拿到大多数实例的锁，要么总耗时超过了锁有效时间），客户端需要向所有Redis实例发起释放锁的请求（使用那个判断unique_value的Lua脚本）。

Redisson提供了RedissonRedLock的实现，用法如下：

RLock lock1 = redissonInstance1.getLock("lock1"); RLock lock2 = redissonInstance2.getLock("lock2"); RLock lock3 = redissonInstance3.getLock("lock3"); RedissonRedLock lock = new RedissonRedLock(lock1, lock2, lock3); // 同时加锁：lock1, lock2, lock3 // 红锁在大部分节点上加锁成功就算成功。 lock.lock(); ... lock.unlock();

重要提醒：RedLock算法在分布式系统社区存在争议（比如Martin Kleppmann曾撰文质疑其安全性）。它需要部署多个独立的Redis主节点，成本较高，且性能会有下降。因此，不要盲目使用RedLock。我的经验是：如果你的业务对锁的绝对安全性要求不是极端苛刻（例如金融核心交易），并且可以容忍在主从故障转移的极小时间窗口内出现极低概率的锁失效，那么使用带有主从复制和故障转移的Redis Sentinel或Cluster，并配合合理的锁超时时间和业务幂等性设计，在99.99%的场景下已经足够可靠。引入RedLock会带来显著的复杂性和运维成本。

6. 性能、超时与重试：高并发下的优化策略

分布式锁是强同步操作，必然对性能有影响。在设计和使用时，必须考虑以下几点：

1. 锁的粒度要尽可能细不要用一把大锁锁住整个系统或整个数据库。锁的Key应该与要保护的资源精确对应。例如，保护“用户A的账户余额”，锁的Key可以是lock:user:balance:{userId}，而不是一个全局的lock:user_balance。这样，不同用户的操作就不会相互阻塞。

2. 设置合理的锁超时时间超时时间太短，业务没执行完锁就释放了，会导致数据错误。超时时间太长，一旦客户端宕机，其他客户端需要等待很久才能获取锁，影响系统可用性。这个时间需要根据压测和业务监控来动态调整。一个技巧是：在锁中记录业务开始时间，在释放时检查业务执行时长，并以此作为调整超时时间的依据。

3. 实现非阻塞的尝试锁与重试机制不要一味地使用阻塞式锁（lock()）。在高并发场景下，这可能导致大量线程挂起，耗尽资源。应该使用尝试锁，并设计退避重试策略。

// Redisson 示例 RLock lock = redisson.getLock("myLock"); // 尝试获取锁，最多等待100秒，获取后锁的持有时间不超过10秒 boolean isLocked = lock.tryLock(100, 10, TimeUnit.SECONDS); if (isLocked) { try { // 处理业务 } finally { lock.unlock(); } } else { // 获取锁失败，可以快速失败，或者记录日志、降级处理 log.warn("获取分布式锁失败，执行降级逻辑..."); }

对于重试，建议使用指数退避算法，例如第一次等待100ms，第二次200ms，第三次400ms...，避免所有客户端同时重试导致“惊群效应”。

4. 避免在锁内执行耗时操作这是基本原则。锁内的代码路径应该尽可能短平快。如果需要调用外部服务、执行复杂查询，要评估其超时风险，并考虑是否可以将这些操作移到锁外，或者使用异步方式。

7. 监控、治理与容灾：让锁的运行状态可视化

分布式锁用上了，不代表就高枕无忧了。没有监控的锁，就像没有仪表盘的汽车，出问题了都无从查起。我们需要建立完善的监控体系：

1. 锁的等待与持有时间监控在客户端代码中埋点，记录每次尝试获取锁的等待时间、锁的实际持有时间。如果平均等待时间过长，说明锁竞争激烈，需要分析是业务热点问题还是锁粒度太粗。如果持有时间经常接近或超过超时时间，说明业务逻辑可能过慢或有风险。

2. Redis Key监控监控作为锁的Redis Key。如果发现某个锁Key长期存在（远超过业务合理时间），可能是客户端崩溃没有释放，需要告警并可能人工介入清理（使用Lua脚本安全清理）。可以监控lock:*这类Key的模式，统计其数量、TTL分布。

3. 设计降级与熔断策略当Redis集群不可用，或者获取锁的失败率超过某个阈值时，系统不能完全崩溃。应该设计降级策略。例如，对于非核心业务（如更新用户浏览次数），可以直接跳过加锁步骤。对于核心业务，可以降级到使用数据库悲观锁（性能差但可靠），或者直接返回“系统繁忙”提示。在Redisson等客户端中，可以配置连接失败时的行为。

4. 定期演练与混沌工程定期模拟Redis节点故障、网络分区等场景，观察分布式锁客户端的行为和业务的反应。这能帮助你真正理解系统的脆弱点，并完善你的应急预案。