ZooKeeper 分布式锁：强一致性下的“排队”哲学

如果说 Redis 锁是**"短跑冠军"** ，追求极致的速度，偶尔可能因为抢跑（主从切换）而犯规；

那么 ZooKeeper (ZK) 锁就是**"精密仪仗队"** ，它不追求快，但追求绝对的秩序和一致。

在金融转账、核心支付、元数据管理等**"绝对不能出错"** 的场景下，Redis 的 AP 模型（最终一致性）是致命的，而 ZK 的 CP 模型（强一致性） 则是唯一的救赎。

今天，我们将深入 ZK 的骨髓，剖析它是如何利用临时顺序节点 和Watcher 机制 ，实现一套天然防死锁、天然无羊群效应的完美锁机制。

核心痛点：为什么 Redis 在"钱"面前显得脆弱

回顾一下 Redis 的致命弱点：

• 异步复制 ：Master 写成功 -> 异步传给 Slave -> Master 挂掉 -> Slave 上位（数据没同步过来） -> 锁丢失。
• 后果 ：两个线程同时拿到锁，同时扣款。超卖 = 资损 = 事故。

生活化比喻：

• Redis 锁 = 春运抢票 。
  大家拼命刷新页面（轮询），手快有手慢无。如果售票系统宕机重启，可能刚才卖出的票记录丢了，导致同一张座位卖给了两个人。
• ZooKeeper 锁 = 银行取号机 。
  你进门按按钮，机器吐出一张纸条：A001。
  下一个进来的人，机器吐出：A002。
  规则铁律 ：只有 A001 办完业务离开，柜员叫号，A002 才能上前。
  哪怕银行停电了（宕机），来电后系统依然记得：A001 没办完，A002 必须等着。绝不会出现两个人同时在柜台办业务的情况。

底层原理：ZK 的"三叉戟"

ZK 实现分布式锁，不需要复杂的 Lua 脚本，也不需要看门狗续期。它利用了三个原生的底层特性，构成了完美的闭环。

1、临时节点 (Ephemeral Node) ------ 解决死锁

• 原理 ：ZK 的节点分为持久化和临时化。临时节点的生命周期与客户端会话 (Session) 绑定。
• 机制 ：
  • 客户端创建 /locks/order-001 (临时)。
  • 只要客户端连接不断开（心跳正常），节点就在。
  • 一旦客户端宕机、网络断开、进程崩溃 ，ZK 服务端检测到 Session 过期，立即自动删除该节点。
• 优势 ：彻底杜绝死锁。不需要任何"看门狗"线程去续期，服务器端自动清理垃圾。

2. 顺序节点 (Sequential Node) ------ 解决公平性与排队

• 原理 ：创建节点时，带上 SEQUENTIAL 标志，ZK 会自动在节点名后追加一个单调递增的序列号（64 位长整型）。
• 机制 ：
  • 线程 A 创建 -> /locks/order-0000000001
  • 线程 B 创建 -> /locks/order-0000000002
  • 线程 C 创建 -> /locks/order-0000000003
• 优势 ：天然形成FIFO (先进先出) 队列。序号最小的节点获得锁。这保证了锁的公平性，避免了某些线程长期饿死。

3. Watcher 监听机制 ------ 解决"羊群效应"

这是 ZK 锁最精妙的设计。

• 什么是羊群效应 (Herd Effect) ？
  • 如果所有等待锁的线程都去监听同一个父节点的变化。
  • 当锁释放（最小节点删除）时，父节点发生变化，所有等待线程同时被唤醒。
  • 它们又蜂拥而去争抢下一个锁，造成巨大的网络风暴和 CPU 抖动。
• ZK 的优化方案 ：
  • 规则 ：每个线程只监听比自己序号小 1 的那个节点（前驱节点）。
  • 流程 ：
    • 线程 B (002) 发现最小的是 001。它不轮询，而是注册一个 Watcher 监听 001 的删除事件。
    • 线程 C (003) 监听 002 的删除事件。
  • 效果 ：
    • 当 001 删除时，只有线程 B 被唤醒。
    • B 醒来检查，发现自己变成了最小，获得锁。
    • B 执行完删除 002，只有线程 C 被唤醒。
  • 结论 ：每次锁释放，仅唤醒一个线程。网络开销 O(1)O(1) ，完美解决羊群效应。

算法全流程拆解 (源码级逻辑)

假设锁路径为 /locks/my_lock。

1. 创建节点 ：

   客户端调用 create("/locks/my_lock-", data, EPHEMERAL | SEQUENTIAL)。

   ZK 返回完整路径，如 /locks/my_lock-0000000005。

2. 获取子节点列表 ：

   客户端调用 getChildren("/locks")，获取所有子节点。

   排序后得到：[...003, 004, 005, 006...]。

3. 判断是否获锁 ：

   检查自己创建的节点 (005) 是否是列表中的第一个。

   • 是 ：直接返回 true，获得锁。
   • 否 ：找到前一个节点 (004)。

4. 注册 Watcher (阻塞等待) ：

   客户端调用 exists("/locks/my_lock-0000000004", watch=true)。

   • 关键点 ：这是一个阻塞调用 （在 Curator 框架内部实现），线程进入 WAITING 状态，不消耗 CPU。
   • 等待事件：NodeDeleted。

5. 唤醒与重试：

   • 当 004 持有者释放锁（删除节点）或宕机（ZK 自动删除）。
   • ZK 服务端发送通知给监听 004 的客户端（即当前线程）。
   • 线程被唤醒，重新执行步骤 2（再次获取列表并判断）。
   • 为什么要重新获取列表？ 防止中间有其他节点插入或并发删除导致的视角不一致。

项目实战：Curator 框架深度解析

原生 ZK API 处理 Watcher 的一次性 特性（Watcher 触发后即失效）非常麻烦。生产环境必须使用 Apache Curator。

import org.apache.curator.framework.CuratorFramework;
import org.apache.curator.framework.recipes.locks.InterProcessMutex;
import java.util.concurrent.TimeUnit;

public class ZkLockDemo {

    private final CuratorFramework client;

    public ZkLockDemo(CuratorFramework client) {
        this.client = client;
    }

    public void executeWithLock(String resourceId, Runnable task) throws Exception {
        // 锁路径
        String lockPath = "/locks/" + resourceId;
        
        // 创建互斥锁对象
        // 底层已经封装了：创建顺序节点、监听前驱节点、异常重试等所有逻辑
        InterProcessMutex lock = new InterProcessMutex(client, lockPath);

        boolean acquired = false;
        try {
            // 尝试获取锁，带超时
            // 如果 10 秒内拿不到锁，抛出异常或返回 false
            acquired = lock.acquire(10, TimeUnit.SECONDS);

            if (acquired) {
                System.out.println("[Thread-" + Thread.currentThread().getName() + "] 获得 ZK 锁");
                
                // --- 临界区业务 (绝对安全) ---
                task.run(); 
                // ---------------------------
                
            } else {
                throw new RuntimeException("获取锁超时，系统繁忙");
            }
        } finally {
            if (acquired) {
                // 释放锁：删除临时节点
                // 如果此时客户端宕机，没执行到这里，ZK Session 过期也会自动删除
                lock.release(); 
                System.out.println("[Thread-" + Thread.currentThread().getName() + "] 释放锁");
            }
        }
    }
}

2. Curator 底层黑盒揭秘

当你调用 lock.acquire() 时，Curator 内部做了极其复杂的工作：

• 节点命名 ：它不会直接用简单的数字，而是生成 lock- + UUID + Sequence，防止极端冲突。
• Watcher 重注册 ：
  • ZK 的原生 Watcher 是一次性的。
  • Curator 内部维护了一个 WatcherManager。如果监听到前驱节点删除，它会先回调业务，然后自动重新注册对新的前驱节点的监听（如果还没轮到你的话）。
• 会话重连 (Connection State Listener) ：
  • 如果网络抖动导致 ZK 连接断开，Curator 会自动重试连接。
  • 关键逻辑 ：在重连期间，如果 Session 没过期，临时节点依然存在，锁不会丢。如果 Session 过期，节点被删，Curator 会感知到 LOST 状态，并抛出 KeeperException，让业务层知道锁已失效，需要重试或回滚。
  • 可重入性 ：
    • Curator 的 InterProcessMutex 也是可重入的。
    • 它使用 ThreadLocal 记录当前线程的重入次数。
    • 第一次加锁创建 ZK 节点，后续重入只增加本地计数，不访问 ZK。
    • 释放时减少计数，归零时才去 ZK 删除节点。

Redis vs ZooKeeper

这个咱们也是对比过好几次

指标	Redis (Redisson)	ZooKeeper (Curator)	差距分析
加锁延迟 (P99)	0.5 ms - 2 ms	15 ms - 40 ms	ZK 涉及磁盘同步 (fsync) 和过半数确认，慢 20 倍以上。
吞吐量 (QPS)	50,000+	2,000 - 5,000	ZK 的写入性能是瓶颈，不适合高并发争抢。
一致性级别	AP (可能丢锁)	CP (强一致)	ZK 只要过半数节点存活，数据绝不丢失。
宕机恢复	依赖过期时间 (秒级)	依赖 Session 超时 (秒级)	两者恢复速度相当，但 ZK 更确定。
适用场景	秒杀、缓存、普通订单	金融、配置、选主	场景决定选型。

数据解读 ：

如果你的接口要求 QPS > 10,000，千万别用 ZK 做锁 ！你会把 ZK 集群打挂，进而拖垮整个依赖 ZK 的注册中心（如 Dubbo），导致雪崩。

ZK 锁适合低频、高价值的操作（如每秒几十次的转账请求）。

ZK 锁专场

Q1: ZooKeeper 分布式锁是如何避免"羊群效应"的？

回答 ：

传统的做法是所有客户端监听同一个父节点，锁释放时所有客户端被唤醒，造成惊群。

ZK 的最佳实践（也是 Curator 的实现）是利用顺序节点 。每个客户端创建顺序节点后，只监听比自己序号小 1 的前驱节点 的删除事件。

当锁释放（前驱节点删除）时，只有一个后继节点会被唤醒。这把 O(N)O(N) 的唤醒开销降低到了 O(1)O(1) 。

Q2: 如果 ZK 集群发生网络分区（脑裂），锁会怎么样？

回答 ：

ZK 是 CP 系统。

• 如果发生网络分区，导致某个分区的节点数不足半数（Quorum），该分区将不可写（无法创建新锁，也无法释放旧锁），客户端会阻塞或报错。
• 只有拥有多数派节点的那个分区才能继续提供服务。
• 结果 ：牺牲了可用性（部分用户无法操作），但保证了数据的一致性（绝对不会出现两个分区各自认为锁有效的情况）。这正是金融场景需要的。

Q3: Curator 的 InterProcessMutex 是可重入的吗？原理是什么？

回答 ：是可重入的。

原理：

1. 首次加锁时，在 ZK 创建临时顺序节点。
2. 在客户端本地（JVM 内存）使用 ThreadLocal<Map<String, Integer>> 记录锁的路径和重入次数。
3. 同一线程再次加锁时，检查 ThreadLocal，发现已持有，直接将计数 +1，不再访问 ZK。
4. 释放时，计数 -1。只有当计数归零时，才向 ZK 发起删除节点请求。

Q4: 既然 ZK 这么稳，为什么不用它替代 Redis 做所有锁？

回答 ：

主要因为性能 和成本。

1. 性能瓶颈：ZK 的写操作需要落盘和过半数确认，延迟是毫秒级的，QPS 远低于 Redis。高并发场景下（如秒杀），ZK 会成为系统瓶颈甚至宕机。
2. 运维成本：ZK 集群的维护和调优比 Redis 更复杂。
3. 场景错配：大部分互联网业务（如点赞、普通下单）可以容忍极低概率的不一致，或者可以通过 DB 兜底，没必要为了 99.99% 的一致性牺牲 10 倍的性能。

结论：高频低价值用 Redis，低频高价值用 ZK。