---
tags: [test/review, architecture, arch/distributed, zookeeper-distributed-lock]
create time: 2026-08-09 12:00
---

# ZooKeeper 分布式锁 — 测试题

## 概述
本测试覆盖 ZooKeeper 分布式锁的核心机制，包括临时顺序节点创建、Watch 一次性触发、公平锁实现原理、ZAB 协议 CP 保证以及与 Redis 锁的系统级对比。共 10 道题目（6 选择 + 3 填空 + 1 简答）。

---

## 一、选择题（6道，由浅入深）

> **难度阶梯**: Q1-Q2 基础概念 → Q3-Q4 核心原理 → Q5-Q6 深入应用/边界场景

### Q1（基础）— 考察定义层面

ZK 分布式锁中创建节点的类型是什么，使得客户端断开连接后能自动清理锁？

A. PERSISTENT — 持久节点，需手动删除
B. EPHEMERAL_SEQUENTIAL — 临时顺序节点
C. PERSISTENT_SEQUENTIAL — 持久顺序节点
D. EPHEMERAL — 临时节点但无序号

### Q2（基础）→ 

以下关于 ZK Watch 机制的说法中，哪一个是正确的？

A. Watch 被触发后会保持注册，持续监听后续变化
B. Watch 是一次性的（One-shot），触发后需要重新注册
C. Watch 只在 `getData` 调用时才会注册
D. Watch 事件通过数据读取通道推送，确保顺序性

### Q3（进阶）— 核心原理

ZK 分布式锁天然实现了公平性，其根本原因是什么？

A. Leader 节点按 FIFO 队列分配锁
B. 使用 SEQUENTIAL 序号决定锁的持有权，按序号大小排序
C. Watch 事件按时间戳排序后分发给等待者
D. ZAB 协议保证了写操作的原子性和有序性

### Q4（进阶）— 比较/辨析

Redis 锁 vs ZK 锁在一致性模型上的主要区别是：

A. Redis 和 ZK 都是 AP 系统
B. Redis 是 CP，ZK 是 AP
C. Redis 单实例是 AP（Redlock 不确定），ZK 是 CP（ZAB 强一致）
D. Redis 是 CP，ZK 是不确定的

### Q5（深入）— 场景推理

N = 3 的 ZK 集群遭遇网络分区，左右各有一个节点。以下描述正确的是：

A. 两边都能正常工作，各自选出新 Leader
B. 左边可以继续写，右边拒绝服务
C. 都无法达成 Quorum，全部停止工作
D. 自动合并为 N=2 集群继续服务

### Q6（深入）— 源码级/边界场景

ZK 会话超时默认 40 秒太长了。根据原文建议，会话超时应该设为多少？同时心跳间隔与会话超时的关系是什么？

A. 建议 1~5 秒；heartbeat = timeout / 5
B. 建议 3~10 秒；heartbeat = timeout / 3
C. 建议 5~15 秒；heartbeat = timeout / 2
D. 建议 10~30 秒；heartbeat = timeout / 4

---

## 二、填空题（3道）

### F1 — 填空1

ZK 分布式锁使用的事件类型是 _____，当子节点列表发生变化时，所有相关监听者都会收到通知。

> **提示**: 这个事件的英文命名直接表达了"节点子列表变化"的含义。

### F2 — 填空2

ZAB 协议的第一个核心阶段是 _____，通过比较 ZXID（事务 ID）选出拥有最大 ZXID 的节点作为 Leader。第二个阶段是 Atomic Broadcast。

> **提示**: 回想 ZAB 的两个核心阶段名称。

### F3 — 填空3

Curator 是 ZK 最流行的 Java 客户端，加锁成功后需要在 finally 块中调用 _____() 方法。该方法会递归释放所有重入计数，而不仅仅是一次 unlock。

> **提示**: Curator 的方法名不是简单的 unlock，而是表达"释放锁"的动作。

---

## 三、简答题（1道）

### S1

某团队正在选型分布式锁方案，有人主张："ZK 锁比 Redis 锁高级，我们应该用 ZK。"请结合原文内容，从以下几个维度给出你的分析并做出选型建议：
- 一致性要求
- 性能需求
- 运维复杂度
- 业务场景匹配度

> **答题框架提示**:
> 1. 先反驳"更高级就更好"的思维误区
> 2. 从三个维度客观对比
> 3. 给出具体场景下的推荐方案

---

## 参考答案与解析

### 选择题答案

| 题号 | 正确答案 | 解析 |
|------|---------|------|
| Q1 | B | EPHEMERAL_SEQUENTIAL = 临时 + 顺序。EPHEMERAL 语义保证 session 断开时自动清理，SEQUENTIAL 提供全局有序性。D 选项 EPHEMERAL 虽然也会自动清理，但没有序号就无法实现公平锁。 |
| Q2 | B | Watch 是一次性的，触发后自动注销。客户端必须在接收到事件后立刻重新注册，否则可能永远不再收到下一次通知。 |
| Q3 | B | 因为节点是 SEQUENTIAL 的，按序号大小决定锁的持有权——最小序号获得锁，其他节点按从小到大依次监听前一个节点。这是天然 FIFO 公平性。 |
| Q4 | C | Redis 单实例是 AP（追求高可用），Redlock 的一致性甚至不确定；ZK 基于 ZAB 协议是 CP（追求强一致性），脑裂时宁可停服也不会出现两把锁同时存在。 |
| Q5 | C | N=3 时 Quorum = 2。每个分区只有 1 个节点，无法达到半数（≥2），所以两个分区都无法工作。这是 CP 系统的必然结果——安全性优先于可用性。 |
| Q6 | B | 建议设为 3~10 秒以更快感知宕机。但 heartbeat interval = timeout / 3，太短的 timeout 会导致心跳过于频繁增加网络开销。 |

### 填空题答案

| 题号 | 答案 | 解析 |
|------|------|------|
| F1 | `NodeChildrenChanged` | ZK 锁场景下关注的是子节点列表的变化。当上一个持有者删除节点后，下一个等待者的 watch 会收到 NODE_DELETED 事件进而 getChildren 重新竞争。 |
| F2 | `Leader Election` | ZAB 的两阶段：① Leader Election 选举 Leader；② Atomic Broadcast Leader 广播 Proposal，Follower 回复 ACK 达到半数后提交。 |
| F3 | `release` | Curator 的 InterProcessMutex.acquire() 支持重入，release() 会递归递减重入计数直到归零才真正发送删除请求。直接用 delete 会导致重入计数未释放。 |

### 简答题参考答案

S1：**参考答案要点**：
1. **"更高级"思维误区**：ZK 不是为"高级"设计的，而是为"强一致性协调"设计的。不要因为技术栈偏好而引入不必要的复杂度。
2. **一致性维度**：如果业务只需要简单互斥（如防止用户重复点击），Redis SET NX 足够好，CP 过度设计。如果需要 Leader 选举等强一致性保证，ZK 更适合。
3. **性能维度**：Redis 百万级 QPS（内存操作），ZK 需写事务日志同步复制，QPS 低一个数量级。高频短锁场景 Redis 明显更优。
4. **运维维度**：Redis 集群工具链成熟，ZK 需要维护奇数节点集群，运维成本高。
5. **结论**：简单互斥 → Redis + SET NX EX；强一致性少量并发控制（Leader 选举、Job 唯一绑定）→ ZK；不要为了"更高级"而上 ZK。

**评分标准**：答出任意 2 个要点即可得满分；完全正确需覆盖全部要点。

## 关联笔记
- [[Redis 分布式锁]]
- [[幂等设计方案]]