大厂生产级 Redis 分布式锁：从原理到避坑实战

在微服务架构和高并发系统中，对共享资源的互斥访问是永恒的主题。单机环境下的 synchronized 或 ReentrantLock 已无法满足跨进程、跨节点的协调需求。此时，分布式锁 便成为保障数据一致性的关键武器。Redis 凭借其高性能、原子性操作和丰富的数据结构，成为了实现分布式锁的首选方案之一。然而，"简单使用 SETNX" 远远不够，本文将带你一步步构建一个真正能扛住大厂流量洪峰的生产级 Redis 分布式锁。

一、为什么需要分布式锁？

设想一个典型的秒杀场景：库存为 1 的商品，有成千上万个请求同时涌入。若无分布式锁，多个服务实例可能同时读取到库存为 1，各自扣减后都成功下单，导致超卖。分布式锁的作用就是确保在同一时刻，只有一个请求能执行"检查库存 -> 扣减库存 -> 创建订单"这一关键业务逻辑。

二、初探：基于 SETNX 的简易锁

SETNX（SET if Not eXists）命令是实现分布式锁最直观的起点。

# 尝试获取锁
SETNX lock:product_123 "locked"
# 如果返回 1，表示获取成功；返回 0 则失败。

​问题​：

1. 死锁风险 ：如果持有锁的服务在执行业务逻辑时崩溃，未能执行 DEL 释放锁，那么这个锁将永远存在，导致后续所有请求被永久阻塞。
2. 非原子性 ：SETNX 和 EXPIRE 是两个独立的操作。如果 SETNX 成功后，服务在执行 EXPIRE 前崩溃，依然会形成死锁。

三、进阶：原子性加锁与自动过期

Redis 2.6.12 版本后，SET 命令得到了增强，可以通过 NX 和 EX/PX 选项在一个原子操作内完成"设置值 + 设置过期时间"。

# 原子性地尝试获取锁，并设置30秒自动过期
SET lock:product_123 "request_id_abc" NX EX 30

• NX：仅当 key 不存在时才设置。
• EX 30：设置 key 的过期时间为 30 秒。

​优势 ​：彻底解决了 SETNX + EXPIRE 非原子性的问题，从根本上规避了因服务崩溃导致的死锁。

​新挑战 ​：如何安全地释放锁？

如果直接使用 DEL lock:product_123，可能会出现以下情况：

• 服务 A 获取了锁，但业务执行时间超过了 30 秒，锁自动过期。
• 服务 B 此时成功获取了同一把锁。
• 服务 A 在执行完业务后，调用 DEL 删除了服务 B 的锁！

这会导致严重的并发安全问题。因此，​释放锁时必须验证锁的持有者身份​。

四、生产级方案：安全释放与可重入设计

1. 安全释放锁

解决方案是将锁的 value 设置为一个​唯一标识​（如 UUID + 线程 ID），并在释放时通过 Lua 脚本进行原子性校验和删除。

-- unlock.lua
if redis.call("GET", KEYS[1]) == ARGV[1] then
    return redis.call("DEL", KEYS[1])
else
    return 0
end

Java 伪代码：

String lockValue = UUID.randomUUID().toString();
Boolean isLocked = redisTemplate.opsForValue().setIfAbsent("lock:product_123", lockValue, Duration.ofSeconds(30));

if (Boolean.TRUE.equals(isLocked)) {
    try {
        // 执行业务逻辑
        doBusiness();
    } finally {
        // 通过Lua脚本安全释放锁
        redisTemplate.execute(unlockScript, Collections.singletonList("lock:product_123"), lockValue);
    }
}

​核心思想​：只有锁的 value 与当前请求的标识完全匹配时，才允许删除。这保证了锁的安全释放。

2. 可重入锁

在复杂的业务逻辑中，一个线程可能需要多次获取同一把锁（例如，方法 A 调用方法 B，两者都需要同一把锁）。为了支持这种场景，我们需要实现​可重入​。

​实现思路​：

• value 设计 ：将 value 设计为 唯一标识:重入次数 的格式，例如 uuid-threadId:2。
• 加锁逻辑 ：
  • 如果 SETNX 成功，说明是首次获取锁，设置 value 为 id:1。
  • 如果 SETNX 失败，则 GET 当前 value。如果 value 的前缀（唯一标识）与当前请求匹配，则将其重入次数 INCRBY，并刷新过期时间。
• 解锁逻辑 ：
  • 通过 Lua 脚本 GET value。
  • 如果标识不匹配，返回失败。
  • 如果标识匹配，将重入次数减 1 (DECRBY)。
  • 如果重入次数变为 0，则 DEL 锁；否则，只更新过期时间。

这个过程比基础版本复杂，但却是生产环境中处理复杂调用链所必需的。

五、高级考量：Redlock 与看门狗

1. Redlock 算法（争议中）

当 Redis 本身采用主从或哨兵架构时，依然存在极端情况下锁丢失的风险（主节点宕机，从节点未同步最新数据即被提升为主）。Martin Kleppmann 和 Redis 作者 Antirez 曾就此展开著名论战。

Redlock 是 Antirez 提出的一种在多个独立 Redis 节点 上实现分布式锁的算法，旨在提供更强的一致性保证。然而，其复杂性和在真实网络环境下的有效性一直备受争议。对于绝大多数业务场景，一个配置了持久化和高可用（如 Cluster）的 Redis 实例配合上述安全锁机制，已经足够可靠。​除非你的业务对一致性有金融级要求，否则不建议轻易引入 Redlock 的复杂性​。

2. 看门狗（Watchdog）机制

锁的过期时间是一个两难选择：设得太短，业务未执行完就过期；设得太长，故障恢复慢。看门狗是一种优雅的解决方案。

• 原理：在成功获取锁后，启动一个后台线程（看门狗）。
• 行为：该线程定期（例如，每 10 秒）检查业务是否仍在执行。如果仍在执行，就自动延长锁的过期时间（例如，再续 30 秒）。
• 终止：当业务执行完毕，主动通知看门狗停止续期，并释放锁。

Redisson 等成熟的客户端库就内置了看门狗机制，极大地简化了开发者的负担。

六、总结与最佳实践

1. 务必使用 SET key value NX EX/PX 原子命令加锁。
2. 锁的 value 必须是全局唯一的请求标识。
3. 释放锁必须通过 Lua 脚本进行原子性校验和删除。
4. 合理评估是否需要可重入和看门狗功能，优先考虑使用 Redisson 等经过大规模验证的成熟客户端库。
5. 为锁设置合理的、尽可能短的过期时间，这是防止死锁的最后一道防线。
6. 做好监控和告警，对长时间持有的锁进行追踪和分析。

分布式锁看似简单，实则暗藏玄机。理解其背后的设计哲学和潜在陷阱，才能在高并发的战场上，用好这把双刃剑，既保障业务的正确性，又不失系统的高性能。