面试复盘：关于 Redis 如何实现分布式锁

---

面试复盘：关于 Redis 如何实现分布式锁

最近参加了一场技术面试，面试官问了一个经典问题："如果让你用 Redis 实现一个分布式锁，你会考虑什么，如何去实现？"这个问题考察了对分布式系统、Redis 特性和锁机制的理解。面试后我进行了复盘，结合自己的回答和后续思考，整理了这篇博客，希望对大家有所帮助。

一、问题拆解：实现分布式锁需要考虑什么？

在回答之前，我快速梳理了分布式锁的核心需求和难点。分布式锁需要在多个节点间保证互斥性，与单机锁有很大不同，我总结了以下关键点：

1. 互斥性

   任何时刻只能有一个客户端持有锁。

2. 安全性（避免死锁）

   如果持有锁的客户端崩溃或网络中断，锁必须能被释放，避免死锁。

3. 高可用性

   Redis 如果是单点部署，宕机可能导致锁不可用，需要考虑高可用方案。

4. 性能

   高并发场景下，获取和释放锁的操作必须高效。

5. 可重入性（可选）

   某些场景可能要求同一客户端多次获取同一锁，需要额外设计。

基于这些，我在面试中给出了初步实现思路，并结合 Redis 的特性进行展开。

---

二、如何用 Redis 实现分布式锁？

Redis 凭借其高性能和原子性操作，非常适合实现分布式锁。以下是我的实现方案，以及面试中的讨论和复盘补充。

1. 基本实现

最简单的分布式锁可以用 Redis 的 SET 命令实现，结合 NX 和 EX 参数。

• 加锁

  SET lock_key unique_value NX EX 30

  • lock_key 是锁的名称。
  • unique_value 是客户端生成的唯一标识（比如 UUID），用于防止误释放。
  • NX 确保互斥性，只有当 lock_key 不存在时才能设置成功。
  • EX 30 设置 30 秒过期时间，避免死锁。

  返回 OK 表示加锁成功，返回 nil 表示锁已被占用。

• 解锁

  为避免误删其他客户端的锁，用 Lua 脚本确保只有持有锁的客户端才能释放：

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

  • KEYS[1] 是 lock_key。
  • ARGV[1] 是 unique_value。
  • 检查锁的值是否匹配，只有匹配时才删除。

2. 为什么用 Lua 脚本解锁？

面试官追问："为什么不用简单的 DEL 命令释放锁？"

我回答："DEL 是无条件的，如果锁过期后被其他客户端重新获取，直接 DEL 会误删别人的锁。Lua 脚本保证了检查和删除的原子性，避免了这个问题。"复盘时我觉得这个回答靠谱，但细节不够清晰，尤其没解释"Lua 在哪里执行""谁是执行主体"以及"检查如何解决误删"。下面详细补充：

• Lua 在哪里执行？

  Lua 脚本是在 Redis 服务端执行的。Redis 从 2.6 版本开始支持内嵌 Lua 脚本，客户端通过 EVAL 命令将脚本发送给 Redis，由 Redis 的单线程执行引擎运行。

• 谁是执行主体？

  客户端（比如用 Java、Python 写的应用程序）是发起者，通过 Redis 客户端库调用 EVAL 命令，将 Lua 脚本和参数（KEYS 和 ARGV）传给 Redis 服务端。Redis 服务端负责执行并返回结果。

• 参数是什么意思？

  • KEYS 是一个数组，表示 Redis 的键名，这里 KEYS[1] 是 lock_key，告诉脚本操作哪个键。
  • ARGV 是一个参数数组，这里 ARGV[1] 是 unique_value，用来验证锁的持有者身份。
  • 脚本中 redis.call("get", KEYS[1]) 获取锁当前的值，redis.call("del", KEYS[1]) 删除锁。

• 检查如何解决误删问题？

  假设客户端 A 加锁后因任务延迟未及时释放，锁因过期被 Redis 自动删除，客户端 B 随后获取了锁。如果此时客户端 A 用 DEL lock_key 释放锁，就会误删客户端 B 的锁。而 Lua 脚本通过 if redis.call("get", KEYS[1]) == ARGV[1] 检查当前锁的值是否仍为 A 的 unique_value，如果不匹配（比如已被 B 占用），脚本返回 0，不执行删除操作。这种原子性检查避免了误删，因为 Redis 的单线程模型保证了 GET 和 DEL 在脚本内不会被其他操作打断。

3. 改进：应对过期时间问题

基本实现有个隐患：如果客户端在锁过期前未完成任务（比如网络延迟），锁会被释放，导致互斥性失效。我提出了以下改进：

• 客户端续期 ：加锁后启动后台线程，定时用 EXPIRE 续期锁，直到任务完成。
• Redlock 算法：如果可靠性要求高，可以用 Redlock，在多个独立 Redis 节点上加锁。

4. 高可用性与 Redlock 详解

面试官问及 Redis 单点故障怎么办，我提到可以用 Sentinel 或 Cluster 部署，但更彻底的方案是 Redlock。下面详细展开：

• Redlock 是什么？依赖什么提供的机制？

  Redlock 是 Redis 官方推荐的分布式锁算法，由 Redis 作者 Antirez 提出。它不依赖单一 Redis 实例，而是基于多个独立 Redis 节点（通常是 5 个或更多）。客户端需要依次向这些节点加锁，只有在超过半数节点（N/2+1）加锁成功，且总耗时小于锁的过期时间，才算获取锁成功。释放锁时，向所有节点发送解锁请求。

• 好处

  • 高可靠性：单节点宕机不影响整体锁机制，只要多数节点存活即可。
  • 避免脑裂问题：相比 Redis Cluster 的主从切换，Redlock 不依赖单一集群，能更好应对网络分区。

• 弊端

  • 性能开销大：需要与多个节点通信，网络延迟会显著影响加锁速度。
  • 复杂度高：实现和维护成本高，客户端需要处理多节点协调。
  • 时间敏感：如果客户端时钟不同步或网络抖动导致超时，可能出现锁失效的风险。
  • 不适合所有场景：对于简单业务，单实例加锁已足够，Redlock 过于复杂。

---

三、复盘中的不足与反思

面试时我覆盖了基本实现和安全性，但有些细节不足：

1. 锁续期细节
   提到续期线程但未细说实现，比如如何确保线程可靠性和退出时机。实际中可以用守护进程或定时任务。
2. Redlock 深度不够
   简单提到 Redlock，没展开其依赖和权衡。复盘后补充了其机制和适用性分析。
3. 性能优化
   高并发下锁争抢会导致自旋等待，可以用 WATCH 或指数退避优化。

---

四、总结

这次面试让我更深入理解了分布式锁。用 Redis 实现分布式锁的核心是利用原子性和过期机制，Lua 脚本解决了释放锁的安全性问题，而 Redlock 提供了更高可靠性但成本也更高。复盘让我意识到回答问题时要注重细节和场景权衡，希望这篇博客对你的面试准备也有启发！