1.3 五大特性与 CAP 取舍：法庭的承诺书

1.3 五大特性与 CAP 取舍：法庭的承诺书

本节摘要：ZooKeeper 对外承诺顺序一致性、原子性、单一视图、可靠性与实时性五项性质，并在 CAP 三角中明确选择 CP——网络分区时宁可拒绝服务，也不给出可能错误的数据。本节逐条拆解承诺内容与背后代价。

一张被误解的成绩单

不少文章把 ZooKeeper 描述成"又快又稳永不丢"，这种说法既对又危险。对，是因为它确实把自己承诺的性质做到了极致；危险，是因为没说清它没承诺什么——比如它不保证跨两次读的全局最新（顺序一致而非线性一致），分区时它干脆拒绝服务。拿它当"更可靠的 Redis"来用，早晚会踩坑。本节的任务是把承诺书逐条读清：每一项性质由什么机制支撑，又付出了什么代价。

承诺书逐条精读

顺序一致性：同一个客户端发出的请求，按发送顺序被执行，且所有服务器看到的写顺序全局一致。注意主体是"同一客户端"——两个不同客户端各自看到的先后可以不同步，这是它与线性一致的差距所在，也是它换性能的地方。支撑它的是 ZAB 协议给每个写请求分配的全局递增事务号（zxid），第四章 4.1 节展开。

原子性：一次写要么在全网生效，要么全网不生效，不存在"三台成功两台失败"的中间态。表决机制保证：只有多数派认可，提案才会提交；未认可的副本事后会被补齐到最新。

单一视图：客户端无论连到集群哪台服务器，看到的数据视图一致。严格说，这是"每个客户端自己视角的一致"——客户端切换连接的服务器时，会话保证不会后退。

可靠性：写成功的回复一旦返回，数据就被多数派持久化，任何一台服务器掉电重启都不会丢。代价是每次写都要落盘日志，写入延迟的下限由磁盘决定。

实时性：客户端能在一个时间窗口内（通常几十毫秒）看到最新状态。它依赖客户端连接自身的会话保活，窗口大小与会话超时配置相关，2.3 节的参数部分再算这笔账。

CAP 那笔交易：用可用性换正确性

CAP 定理说，一致性、可用性、分区容忍三者不可兼得。ZooKeeper 的选择是 CP：平时网络正常，一致与可用都有；一旦发生网络分区——比如五台机器被光缆挖断成两半三台——少于多数派的那一侧会整体停止服务，包括读请求。

初学者常在这里卡住：为什么读也不让读？设想分区后小侧还继续提供读服务，一个客户端在小侧查到"主节点是 A"，另一个在大侧查到"主节点已切换为 B"，两个上游系统各持一份真相去操作同一份资源——这正是脑裂，第六章 6.1 节的教训。书记员宁可闭庭，也不出一份可能自相矛盾的证明，这个"罢工权"恰恰是它存在的价值。

图：CAP 三角上的三种立场对比

用四字命令亲眼验证

Cluster 状态不是黑盒。ZooKeeper 提供一组四字命令，用 telnet 或 nc 直接向 2181 端口发送即可查看内部状态：

# srvr：查看服务器角色与统计
$ echo srvr | nc 127.0.0.1 2181
Zookeeper version: 3.8.4, built on 2024-02-12
Latency min/avg/max: 0/0.5/12
Received: 81234
Sent: 81230
Connections: 4
Outstanding: 0
Zxid: 0x2a0000001f          # 全局事务号，每次写递增
Mode: follower              # 本机角色：follower / leader / standalone
Node count: 58

# mntr：机器可读格式，监控脚本常用
$ echo mntr | nc 127.0.0.1 2181
zk_version  3.8.4
zk_server_state  follower
zk_zxid  0x2a0000001f
zk_outstanding_requests  0
zk_num_alive_connections  4
​

Mode 行就是角色自报家门。把三台集群里的 leader 停掉，再到 follower 上执行同样的命令，几秒内你会看到某台 follower 的 Mode 变成 leader——这就是第四章选主机制的外部表现。Zxid 则是顺序一致性的直接证据：同一集群任何两台机器的 zxid 之差，只可能来自同步延迟，不可能出现"你有一条我没有的事务"长期存在。

要点回顾

• 五项承诺：顺序一致、原子、单一视图、可靠、准实时，每项都对应具体机制支撑，第四章逐一兑现。
• CP 的含义很具体：分区时少数派侧拒绝一切请求，包括读，这是防止脑裂的主动选择而非缺陷。
• 顺序一致的边界：只保证同一客户端的顺序与全局写序一致，跨客户端的实时线性一致不在承诺内。
• 四字命令是体检仪：srvr 看角色与 zxid，mntr 供监控采集，排障第一手资料从这里来。

常见疑问

问：那我的读密集业务岂不是会被分区误伤？ 会，而且这是设计意图。如果你需要的只是"最终一致的服务发现"，可以接受短暂读到旧列表，那么 etcd、Consul 或 AP 型注册中心可能更贴合。选型话题第七章 7.3 节专门对比。

第二章起，我们离开纸面，把这座法庭真正搭起来。

顺带一段家谱：它从哪里来

ZooKeeper 不是凭空设计的。它源自雅虎研究院为内部 Hadoop 集群解决协调难题的项目，设计大量参考了 Google 发表的 Chubby 论文——那个大名鼎鼎的名字来自著名生产故障的轶事：拼写失误让工程师们记住了它。2010 年它从 Hadoop 子项目晋升为 Apache 顶级项目，此后长期作为大数据生态的默认协调层。了解这段出身有助于理解它的性格：它是为"集群里谁说了算"这类问题而生的，天生就是基础设施，而不是应用组件。

顺序一致的体感：一个可复现的小实验

顺序一致与线性一致的差距，用两个终端就能体会到。终端 A 高频写，终端 B 紧跟着读：

# 终端 A：连续写入三次，每次带不同版本值
[zkA] set /seq-demo "v1"
[zkA] set /seq-demo "v2"
[zkA] set /seq-demo "v3"

# 终端 B：几乎同时开始读。你可能会看到这样的序列：
[zkB] get /seq-demo   # v1   <-- 落后副本给出的旧值，合法
[zkB] get /seq-demo   # v3
[zkB] get /seq-demo   # v3
# 注意：B 看到的一定是 v1 之后才可能出现 v3，不会倒退为 v2 之前的值
# 这是"顺序一致"：各自的序列都单调，但 B 的开头可以落后于 A 的进度
​

这个实验解释了两个工程问题的答案。为什么读多写少是它的甜区——读的旧值窗口在副本间由会话机制约束，多数查询场景无感；为什么金融级强一致读要先 sync——sync 把本次连接对齐到 Leader 的进度，之后的读就不再落后。把承诺书的边界背成体感，选型时才不会把不适合的场景错交给它。

延伸追问

问：既然读可能落后，为什么它还敢叫强一致？ 业界对"强一致"的用法很宽。ZooKeeper 承诺的是"写入的全序与原子可见"，这在协调场景（锁、选主）已经足够；它与"所有读都立即反映最新写"的线性一致有明确差距。协议术语上称顺序一致性，选型时按这个词去对照需求，不要被宣传词带偏。