01

60 秒回答模板

Redis 分布式锁的单点问题分两层：单实例宕机会导致锁服务不可用；主从异步复制下，主节点写锁成功但还没复制给从节点就宕机，从节点升主后可能没有这把锁，另一个客户端又加锁成功，从而出现两个客户端都认为自己持锁。普通业务可以用 Sentinel/Cluster 提升可用性，并用唯一 value、TTL、Lua 释放、幂等和补偿降低风险；更强互斥要考虑 Redlock 多主多数派、ZooKeeper/etcd 临时节点、数据库唯一约束和 fencing token。高可用不等于严格互斥。

考点 核心机制与工程取舍
难度 中高频面试题
回答目标 按定义、机制、场景讲清楚
02

深入解析

01

先说清故障时间线

客户端 A 在主 Redis 加锁成功，主节点还没把锁复制到从节点就宕机；从节点升主后没有 A 的锁，客户端 B 加锁成功。此时 A 和 B 都可能执行业务。

02

Sentinel 和 Cluster 解决的是可用性

它们能自动故障切换或分片扩容，降低 Redis 不可用时间，但异步复制窗口仍可能丢锁。不能把主从高可用直接等同于锁安全。

03

`WAIT` 只能降低风险

写锁后等待若干副本确认可以降低丢锁概率，但在超时、网络分区、故障切换和副本确认语义下，仍不能简单证明严格互斥。

04

方案要按业务安全等级分级

普通防重复任务可用 Redis 锁加幂等补偿；强一致写入更适合 ZK/etcd、数据库约束或带 fencing token 的租约机制；跨资源事务不应只靠 Redis 锁。

05

Redlock 也要说明前提

Redlock 用多个独立 Redis 节点，多数派加锁成功且总耗时小于租约才算获得锁。它依赖时间窗口和时钟漂移假设，强一致场景仍建议配 fencing token。

03

易错点

  • 把主从复制或 Redis Cluster 等同于严格分布式锁。
  • 只提升锁服务可用性，不证明业务互斥性。
  • 忽略锁丢失后的幂等、状态机校验和补偿。
  • 讨论 Redlock 时不提租约时间、时钟漂移和 fencing token。
04

面试官追问

Redis 集群就一定解决锁安全了吗？

不一定。集群提升可用性和容量，但互斥安全仍受复制、切换和租约过期影响。

Redlock 是不是绝对安全？

不是绝对。它提高单点故障下的安全性，但依赖租约时间、时钟漂移和网络延迟假设。强写入还要用 fencing token 或数据库约束兜底。

为什么需要 fencing token？

锁过期或网络隔离后，旧客户端可能继续写。fencing token 让下游按单调递增版本拒绝旧请求，避免旧持有者覆盖新结果。

什么时候不用 Redis 锁？

金融级互斥、锁持有时间长、需要公平排队或强会话语义时，更适合 ZK/etcd 或数据库约束。