Redis 分布式锁深度解析

0 经典面试开场

# 一条命令：原子性地完成 加锁 + 设置过期时间
SET lock_key unique_value NX EX 30

# 参数说明：
#   NX  — 只在 key 不存在时才设置（Not eXists）
#   EX  — 过期时间，单位秒（PX 是毫秒）
#   unique_value — 唯一标识（用于安全释放锁）

1 什么是分布式锁？为什么用 Redis？

为什么选择 Redis 做分布式锁？

2 基础实现与致命缺陷

2.1 错误姿势：SETNX + EXPIRE（非原子）

// ❌ 两步操作不是原子的，中间可能 crash
Boolean locked = jedis.setnx("lock:order:1001", "1");
if (locked) {
    // ⚡ 如果这里进程 crash 了，锁永远不会释放！
    jedis.expire("lock:order:1001", 30);
    // 执行业务逻辑...
    jedis.del("lock:order:1001");
}

2.2 正确姿势：SET NX EX（原子操作）

// ✅ 一条命令原子完成，不会有中间状态
String result = jedis.set(
    "lock:order:1001",      // key
    "550e8400-e29b-41d4-a716", // value = 唯一标识
    "NX",                     // 不存在才设置
    "EX",                     // 过期时间单位：秒
    30                        // 30 秒超时
);
if ("OK".equals(result)) {
    // 获取锁成功
}

// 或者用更简洁的 SetParams（Jedis 3.0+）
String result = jedis.set(
    "lock:order:1001",
    "550e8400-e29b-41d4-a716",
    SetParams.setParams().nx().ex(30)
);

// ✅ Go 版本
ok, err := rdb.SetNX(ctx, "lock:order:1001", uniqueID, 30*time.Second).Result()
if ok {
    // 获取锁成功
}

3 Redis 分布式锁的五大核心问题

即使用了 SET NX EX，Redis 分布式锁在实际生产中仍然面临以下问题。每个问题都可能造成严重的线上事故。

• 问题一：误解锁 — 把别人的锁释放了

  问题场景

  客户端 A 拿到了锁，但业务执行时间超过了锁的过期时间，锁自动释放了。此时客户端 B 拿到了锁，结果 A 执行完业务后去释放锁，把 B 持有的锁给释放了。

  解决方案

  加锁时设置一个唯一标识（如 UUID），释放锁时先判断是不是自己加的锁，是才释放。判断 + 释放必须用 Lua 脚本保证原子性。

  A 拿到锁

  →

  A 超时，锁过期释放

  →

  B 拿到锁

  →

  A 把 B 的锁删了!
  Lua 原子释放锁

  -- Lua 脚本：原子性地判断 + 释放
  if redis.call("get", KEYS[1]) == ARGV[1]
  then
      return redis.call("del", KEYS[1])
  else
      return 0
  end

  🔑 为什么用 Lua？ Redis 执行 Lua 脚本期间，其他命令无法插入执行，保证了 GET + DEL 的原子性。

  🔑 为什么要唯一标识？ 不能用 PID 或 Thread ID，因为不同 JVM / 容器的 PID 可能重复。用 UUID + 线程ID 的组合最可靠。

• 问题二：锁过期，业务没执行完

  问题场景

  设置锁过期 30 秒，但业务逻辑因为 GC 停顿、网络延迟、数据库慢查询等原因执行了 35 秒。在第 30 秒时锁自动释放，另一个线程进来，两个线程同时执行，数据就乱了。

  解决方案

  看门狗机制（Watchdog）：获取锁后启动一个后台线程，定期（如每 10 秒）检查锁是否还被当前线程持有，如果是就自动续期（延长过期时间）。Redisson 内置了这一机制。

  Java — Redisson 看门狗

  // Redisson 默认开启看门狗机制
  // lockWatchdogTimeout 默认 30 秒，每 10 秒续期一次
  RLock lock = redissonClient.getLock("lock:order:1001");
  
  // 方式1：不传超时时间 → 启动看门狗，默认30s看门狗
  lock.lock();
  
  // 方式2：传超时时间 → 不启动看门狗，到期自动释放
  lock.lock(30, TimeUnit.SECONDS);
  
  // 正确姿势：用 tryLock 带超时
  boolean locked = lock.tryLock(
      10,                    // waitTime：最多等 10 秒拿锁
      30,                    // leaseTime：锁 30 秒后自动释放
      TimeUnit.SECONDS
  );

  参数	看门狗行为
  lock() 不传 leaseTime	✅ 启动看门狗，默认 30 秒，每 10 秒续期
  lock(30, SECONDS)	❌ 不启动看门狗，30 秒后自动释放，不续期
  tryLock(waitTime, leaseTime, unit)	❌ 指定了 leaseTime 不启动看门狗

• 问题三：主从切换导致锁丢失

  问题场景

  客户端 A 在 Master 上拿到了锁，还没来得及同步到 Slave，Master 宕机了。Slave 被提升为新 Master，但锁数据丢失了。此时客户端 B 在新 Master 上拿同一把锁，就会成功 — 两个客户端同时持有锁！

  解决方案

  RedLock（红锁）算法：不在单个 Redis 实例上加锁，而是向 N 个独立的 Redis 实例（通常是 5 个）同时请求加锁。只有在大多数实例（N/2+1）上成功，且总耗时小于锁的有效时间，才算获取锁成功。

  A → Master 拿到锁

  →

  Master 宕机

  →

  Slave → 新 Master

  →

  锁数据丢失

  →

  B 也拿到锁!

  ⚡ RedLock 核心：向 N 个独立 Redis 节点（建议 5 个）依次请求加锁 → 计算总耗时 → 拿到 N/2+1 个节点（即多数）的锁 且 总耗时 < 锁有效期 → 才算成功。释放时向所有节点发释放命令。

  Java — Redisson RedLock

  // 三个独立的 Redis 实例（不要用同一集群的主从）
  RLock lock1 = redissonClient1.getLock("lock:order:1001");
  RLock lock2 = redissonClient2.getLock("lock:order:1001");
  RLock lock3 = redissonClient3.getLock("lock:order:1001");
  
  // 红锁 = 多数派投票
  RLock redLock = redissonClient1.getRedLock(lock1, lock2, lock3);
  
  // 使用和普通锁一样
  redLock.lock();
  try {
      // 业务逻辑
  } finally {
      redLock.unlock();
  }

  🤔 RedLock 的争议

  Redis 作者 Antirez 提出了 RedLock 算法，但分布式系统专家 Martin Kleppmann 提出了反对意见，认为 RedLock 在时钟跳跃、GC 停顿等场景下仍有安全问题。如果你的业务对一致性要求极高（如金融扣款），建议使用 ZooKeeper 或 etcd 这类基于共识协议的方案。

  实用建议：绝大多数互联网业务场景，单节点 Redis + 看门狗 + Lua 释放已经足够。真正需要 RedLock 的场景很少。

• 问题四：可重入性问题

  问题场景

  同一个线程如果递归调用或调用链中有同一把锁的方法，第二次获取锁时会失败——因为 SET NX 发现 key 已经存在，返回失败，导致线程自己阻塞自己。

  解决方案

  在锁的 value 中维护一个计数器（或使用 Hash 结构）。加锁时判断是否是同一个客户端（通过唯一标识），如果是则计数器 +1；释放时计数器 -1，到 0 才真正删除 key。Redisson 的 RLock 天然支持可重入。

  Redisson 可重入原理（简化版 Lua）

  -- 加锁脚本（简化）
  if redis.call('exists', KEYS[1]) == 0 then
      redis.call('hincrby', KEYS[1], ARGV[2], 1);      -- 首次加锁，计数=1
      redis.call('pexpire', KEYS[1], ARGV[1]);
      return nil;  -- 成功
  end;
  if redis.call('hexists', KEYS[1], ARGV[2]) == 1 then
      redis.call('hincrby', KEYS[1], ARGV[2], 1);  -- 重入，计数+1
      redis.call('pexpire', KEYS[1], ARGV[1]);
      return nil;  -- 成功
  end;
  return redis.call('pttl', KEYS[1]);  -- 失败，返回剩余时间

• 问题五：锁竞争与性能

  问题场景

  高并发下大量线程自旋重试获取锁（while true 循环 + sleep），CPU 空转、Redis 压力增大、无效网络请求增多。

  解决方案

  使用 发布/订阅 + 信号量：锁释放时发布消息通知等待的线程，而不是轮询。Redisson 的 RLock 底层使用了 Redis 的 Pub/Sub 机制来实现高效的等待唤醒。

4 问题总结对照表

5 生产环境最佳实践

public void processOrder(String orderId) {
    RLock lock = redissonClient.getLock("lock:order:" + orderId);
    boolean locked = false;
    try {
        // 最多等 5 秒，拿到锁后 30 秒自动释放
        locked = lock.tryLock(5, 30, TimeUnit.SECONDS);
        if (!locked) {
            throw new RuntimeException("获取锁超时");
        }
        // === 业务逻辑 ===
        doBusinessLogic(orderId);
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
    } finally {
        if (locked && lock.isHeldByCurrentThread()) {
            lock.unlock();  // 安全释放
        }
    }
}

6 Redis vs ZooKeeper vs etcd 分布式锁对比