红锁RedLock

红锁：
可以按“是什么 → 为什么需要 → 怎么实现 → 有什么缺陷 → 工程上怎么选”来答。

红锁是什么？

红锁 RedLock 是 Redis 作者提出的一种多节点分布式锁算法。它不是 Redis 内置命令，而是一种算法思想，Java 里常用 Redisson 的 RedissonRedLock 来实现。

它的核心思路是：部署 N 个完全独立的 Redis 主节点，通常推荐 5 个；客户端向这些节点分别加锁，只要成功获取到 超过半数节点，比如 5 个里拿到 3 个，并且加锁总耗时小于锁的有效期，就认为加锁成功。

为什么需要红锁？

普通 Redis 分布式锁一般是：

SET lock_key uuid NX PX 30000

但在 主从架构 下会有问题：客户端在 master 拿到锁后，锁数据还没来得及同步到 slave，master 宕机，slave 提升为新 master，这把锁就丢失了。此时另一个客户端可能也拿到同一把锁，导致两个客户端同时进入临界区。

RedLock 就是为了解决这种主从切换丢锁、单点故障的问题。

红锁的加锁流程

以 5 个独立 Redis 节点为例：

1. 客户端生成唯一标识，比如 UUID。

2. 记录开始时间 T1。

3. 依次或并行向 5 个节点执行：
   SET key uuid NX PX ttl

4. 统计成功加锁的节点数量。

5. 如果成功节点数 ≥ N/2 + 1，并且 T2 - T1 < ttl，则认为加锁成功。

6. 锁的真实有效时间 = ttl - 加锁耗时。

7. 如果加锁失败，要向所有节点发送释放命令，清理残留锁。

解锁流程

解锁时不能简单 DEL，需要用 Lua 脚本保证原子性：

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

也就是：只有 value 是自己持有的 uuid 时，才删除锁，防止误删别人的锁。

红锁的缺陷，面试一定要提

红锁理论上有容错能力，但工程上争议很大：

• 强依赖时钟：如果节点时钟漂移、NTP 校正，可能导致锁有效期判断异常。

• 无法解决 GC 停顿：客户端发生 STW 停顿后，可能锁已经过期，但客户端仍认为自己持有锁。

• 网络延迟敏感：加锁需要和多节点通信，性能比单节点锁差。

• 运维成本高：需要维护多个完全独立的 Redis 实例。

• Redisson 已废弃 RedLock：生产环境不建议直接用它做强一致性锁。

面试收尾可以这样说

如果业务对并发安全要求不是极端严格，通常用 单机 Redis + 唯一值 + 过期时间 + Redisson 看门狗续期 就够了。
如果要求强一致性、绝对不能出现并发冲突，更推荐用 Zookeeper 或 etcd 这类基于一致性协议的分布式锁。

这样答，面试官会觉得你不仅知道 RedLock 原理，也了解它的边界和工程取舍。

---

要不要说说 Redisson 看门狗续期的原理？这是单机 Redis 锁避免业务卡死的关键，面试也常问。