Redis 实现分布式锁时可能遇到的问题有哪些？

Redis 分布式锁实现中的核心问题与解决方案

Redis 分布式锁是通过 Redis 的原子性操作，在分布式系统中实现互斥访问共享资源的一种协调机制，其本质是在 Redis 中设置一个具有特定标识和生命周期的键值对来代表锁的持有状态。

死锁风险：客户端获取锁后崩溃，锁无法自动释放。解决方案是为锁设置合理的过期时间（TTL）。
误删锁问题：客户端 A 的锁过期后被 B 获取，此时 A 完成操作并误删 B 的锁。解决方案是使用唯一标识（如 UUID）作为锁的值，删除时验证标识匹配。
锁续期难题：业务操作时间可能超过锁的过期时间。解决方案是实现“看门狗”机制自动续期，或使用 Redlock 等成熟算法。
集群环境下的可靠性问题：主从切换可能导致锁状态丢失。解决方案是使用 Redlock 算法在多个独立 Redis 节点上同时获取锁。
性能与可用性平衡：频繁的锁竞争会影响系统吞吐量。解决方案是合理设计锁粒度、使用非阻塞的尝试获取锁机制。

场景还原：

解决方案实现：

-- Lua 脚本保证原子性
if redis.call("GET", KEYS[1]) == ARGV[1] then
    return redis.call("DEL", KEYS[1])
else
    return 0
end

Redlock 用于解决单点故障问题，要求至少 5 个独立的 Redis 主节点：

Step 1：客户端记录当前时间 T1 Step 2：依次向 N 个节点发送 SET 命令（包含唯一值、过期时间） Step 3：计算获取锁耗时 = 当前时间 T2 - T1 Step 4：判断成功条件：

为什么 Redlock 建议使用 5 个节点而不是 3 个？
- 5 个节点允许最多 2 个节点故障（N/2+1=3），提供了更好的容错能力
- 3 个节点只能容忍 1 个节点故障，故障概率相对较高
SETNX 和 SET 命令在实现分布式锁时有什么区别？
- SETNX 是原子性的“不存在才设置”，但需要额外命令设置过期时间，不是原子操作
- Redis 2.6.12+ 的 SET 命令支持 NX 和 EX 参数，可以原子性地完成“设置值+过期时间”
如何避免锁过期时间设置不当的问题？
- 采用“看门狗”机制：启动后台线程，在锁过期前定期续期
- 合理评估业务最长时间，设置缓冲时间（如业务预估 10s，设置 TTL=30s）
- 使用可重入锁记录持有次数，确保只有最后一次释放才真正删除锁
Redis 集群模式下分布式锁有什么特殊问题？
- 异步复制延迟：主节点写入锁后，在复制到从节点前崩溃，可能导致锁丢失
- Redlock 算法正是为解决此问题而设计，但仍有争议（见 Martin Kleppmann 的分析）