Redis 分布式锁实战宝典：原理、避坑与性能优化

Redis 分布式锁的核心目标是在分布式系统中保证多个节点对共享资源的互斥访问，其原理基于 Redis 的单线程特性、原子操作和过期机制，核心思路是「通过抢占唯一的 Redis 键来获取锁，释放锁时删除该键」，同时解决锁超时、误释放、重入等问题。

一、核心原理（基础版）

分布式锁的核心是利用 Redis 的以下特性实现互斥：

1. 单线程原子性：Redis 执行命令是单线程的，单个命令（如 SET、DEL）天然原子性，可避免并发竞争；
2. 键的唯一性：为共享资源定义唯一的锁键（如 lock:order:123），只有成功创建该键的节点能获取锁；
3. 过期机制：避免节点持有锁后宕机导致锁永久无法释放（死锁）。

基础实现步骤（伪代码）

# 1. 获取锁：SET 命令（原子操作）
def acquire_lock(lock_key, client_id, expire_time):
    # SET key value NX EX：仅当键不存在时创建（NX），并设置过期时间（EX，秒）
    result = redis.set(lock_key, client_id, nx=True, ex=expire_time)
    return result is True

# 2. 释放锁：DEL 命令（需先验证归属，避免误删）
def release_lock(lock_key, client_id):
    # 先查再删非原子，生产需用 Lua 脚本
    if redis.get(lock_key) == client_id:
        redis.delete(lock_key)
        return True
    return False

二、关键特性与解决的问题

1. 原子性保障（核心）

基础版的「查再删」存在并发风险（如 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

Redis 执行 Lua 脚本时会阻塞其他命令，确保「验证归属 + 删除键」是原子操作。

2. 避免死锁（过期时间）

• 必须为锁设置过期时间（EX/PX 参数），即使持有锁的节点宕机，Redis 也会自动删除锁键，释放锁；
• 过期时间需合理：太短可能导致业务未完成锁就释放，太长会降低并发效率。

3. 锁的唯一性（客户端标识）

• 锁的值不能是固定值（如 1），必须用唯一客户端标识（如 UUID + 线程 ID），否则可能出现：节点 A 持有锁但超时，节点 B 抢到锁，A 执行完业务后误删 B 的锁；
• 客户端标识确保只有锁的持有者能释放锁。

三、进阶问题与解决方案

1. 锁超时问题（业务未完成锁已释放）

• 问题：若业务执行时间超过锁的过期时间，锁会提前释放，导致多个节点同时操作资源；
• 解决方案：锁续命（Watch Dog 机制）：获取锁后，启动一个后台线程，每隔 过期时间/3 检查锁是否仍归属自己；若仍持有锁，自动延长过期时间（如 Redisson 的 Watch Dog 机制）。

2. Redis 集群下的锁失效（脑裂问题）

• 问题：主从集群中，主节点写入锁后宕机，锁未同步到从节点，从节点升级为主节点，其他节点可重新获取锁；
• 解决方案：Redlock 算法（Redis 官方推荐）：部署多个独立的 Redis 节点（至少 3 个）；客户端向所有节点申请锁，仅当超过半数节点成功且总耗时≤锁过期时间，才认为锁获取成功；释放锁时，向所有节点删除锁键；缺点：实现复杂，性能降低，需权衡一致性与性能。

3. 重入锁问题

• 问题：同一客户端多次获取同一把锁，基础版会导致死锁；
• 解决方案：基于 Hash 结构记录「客户端标识 + 重入次数」：

四、常见实现方案对比

五、核心总结

Redis 分布式锁的本质是：

1. 原子抢占：通过 SET NX 原子抢占唯一键，保证互斥；
2. 安全释放：用 Lua 脚本原子验证并删除锁，避免误释放；
3. 防死锁：设置过期时间 + 锁续命，避免锁永久占用；
4. 集群兼容：Redlock 算法解决主从脑裂导致的锁失效问题。

生产环境优先使用成熟的客户端（如 Redisson），避免重复造轮子，同时根据业务场景选择基础锁或 Redlock 算法。