分布式锁深度解析：Redis、etcd 与 ZooKeeper 三种实现与选型指南

单机锁：
  synchronized / ReentrantLock
  → 作用于「单个 JVM 进程」内的线程
  → 进程内互斥有效

问题：系统拆成 N 个节点后
  - 每个节点各自 JVM 内互斥，节点间不互斥
  - 两个节点可以同时执行同一段临界区代码
  → 需要「跨进程」的互斥机制 = 分布式锁

# 加锁：仅当 key 不存在时设置，并带过期时间（原子操作）
SET lock:order product-01 NX EX 30
# 返回 OK → 加锁成功；返回 nil → 锁已被占用

# 业务处理...

# 释放：必须校验 value（自己的标识）后才能删，防止误删别人的锁
if redis.call("get", KEYS[1]) == ARGV[1] then
  return redis.call("del", KEYS[1])
else
  return 0
end

看门狗机制（Redisson）：
  - 默认锁超时 30s，看门狗每 10s 检测一次
  - 若业务未结束，自动把锁续期到 30s（续命）
  - 业务结束 → 主动释放锁 → 看门狗停止
  → 既防止业务过长锁被误释放，又防止持锁者宕机锁永不过期

自定义方案：
  用一个后台线程定时执行 Lua：若 value 匹配则 EXPIRE 续期
  → 续期前确认锁仍属于自己，否则停止续期

问题场景：
  1. A 在主节点加锁成功
  2. 主节点宕机，锁未复制到从节点
  3. 从节点晋升为主节点，B 加锁成功
  → A 和 B 同时持锁，互斥被打破

应对：
  - 业务上容忍极低概率的双执行（幂等兜底）
  - 或使用 RedLock（多节点投票，下面讲）
  - 或直接改用 etcd/ZooKeeper（强一致存储）

基于 etcd 的分布式锁（etcdv3 API）：
  1. 创建租约 Lease（如 10s），自动续约
  2. 用租约关联一个 Key：client 在指定前缀下写入
     /lock/xxx/client-1（带 lease id）
     → 只有写入成功且 Revision 最小的那个 client 持锁
  3. 客户端 Watch 前缀 /lock/xxx/
     → 当前持锁者释放/超时后，下一个 Revision 最小者获锁
  4. 释放 = 删除自己的 Key（或租约过期自动删除）

Revision（全局单调递增版本号）保证了公平性：
  先写入者 Revision 小 → 先获锁

核心要点：
  - 用 Lease + KeepAlive 保持锁活跃，业务结束 revoke 租约
  - 用前缀 + Revision 实现公平排队（FIFO）
  - Watch 前一个持锁者，避免所有等待者同时抢（羊群效应）
  - 释放用事务 CompareAndSwap：确认 Revision 是自己才删除

与 Redis 锁的关键差异：
  - etcd 是强一致 → 无丢锁窗口
  - 但吞吐低于 Redis，锁获取延迟略高
  - 适合对一致性要求高的场景（配置、选主、分布式事务协调）

基于 ZooKeeper 的分布式锁：
  1. 在锁节点 /lock 下创建临时顺序子节点 /lock/seq-0000000001
  2. 检查自己是不是序号最小的节点
     → 是 → 获得锁
     → 否 → 监听前一个（序号比自己小且最接近的）节点
  3. 前一个节点释放（删除/会话超时）→ 触发通知 → 再检查自己
  4. 获得锁的节点 = 序号最小者；释放 = 删除自己的节点

临时节点的特性：
  - 客户端会话断开 → 临时节点自动删除 → 锁自动释放
  → 持锁者宕机不会死锁（活性）
  → 且会话必须靠心跳维持，网络抖动时锁可能短暂释放

RedLock 加锁流程（N 通常为 5）：
  1. 对每个独立 Redis 实例依次 SET key value NX EX ttl
  2. 记录总耗时，若满足：
     加锁成功的实例数 > N/2，且总耗时 < TTL
     → 加锁成功
  3. 释放：对所有实例执行删除（Lua 校验 value）

思想：
  用「多数派」抵御单点故障
  → 即便个别节点宕机/丢锁，多数派仍持锁

实践结论：
  - 若要求"绝对互斥"，RedLock 并不能提供数学上的保证
  - 若业务可以容忍极小概率双执行（配合幂等兜底），
    单 Redis + 看门狗通常够用
  - 若业务绝对不能接受双执行（扣款、转账），
    建议直接上 etcd/ZooKeeper 或分布式事务

高并发、可容忍极小概率双执行
  → Redis + 看门狗（最常见，成本最低）

高并发且绝对不容忍双执行
  → etcd（云原生标配）或 ZooKeeper

已有 ZooKeeper/etcd 集群，不想多维护一套
  → 直接用现有协调服务做锁

补充：无论哪种锁，业务侧都应做「幂等兜底」
  → 锁只是降低并发概率，幂等保证最终正确

□ 加锁用 SET key value NX EX 原子命令（Redis）
□ value 用业务唯一标识，释放前 Lua 校验
□ 必设 TTL + 看门狗续期，防死锁防误释放
□ 临界区尽量小，锁内不做重 IO
□ 绝对互斥场景选用 etcd/ZooKeeper
□ 高并发场景配合幂等兜底（唯一索引/状态机）
□ 加锁失败采用监听唤醒而非盲目自旋
□ 定期检查锁的超时设置与业务耗时匹配度

分布式锁 = 互斥 + 防死锁 + 防误删，
选型上「性能优先用 Redis、一致性强求用 etcd/ZK」，业务侧永远配幂等兜底。