聊一聊ZooKeeper的顺序一致性（转）

add by zhj: 原文有音频朗读

原文：https://time.geekbang.org/column/article/239261

作者：极客视点

你好，欢迎收听极客视点。

ZooKeeper 作为分布式应用系统协调服务，在分布式系统中的应用非常广泛，在某些业务场景下甚至可以作为注册中心、分布式锁来使用。ZooKeeper 之所以能有如此广泛的应用，与它良好的数据一致性保障机制是分不开的。最近，奈学教育 CTO 孙玄联合陈东在公众号“架构之美 ”聊了聊 ZooKeeper 的顺序一致性，希望对你有所启发。

众所周知，ZooKeeper 专门设计了 Zab（Zookeeper Atomic Broadcast）协议作为其数据一致性协议。利用 Zab 协议的数据写入由 Leader 结点协调，使用两阶段提交的方式，达到数据的最终一致性。为什么是最终一致性呢？我们先了解下两阶段的过程，如图一所示：

 数据写入过程如下：

• 第一阶段：每次的数据写入事件作为提案广播给所有 Follower 结点；可以写入的结点返回确认信息 ACK；
• 第二阶段：Leader 收到一半以上的 ACK 信息后确认写入可以生效，向所有结点广播 COMMIT 将提案生效。

根据写入过程的两阶段的描述，可以知道 ZooKeeper 保证的是最终一致性，即 Leader 向客户端返回写入成功后，可能有部分 Follower 还没有写入最新的数据，所以是最终一致性。

ZooKeeper 保证的最终一致性也叫顺序一致性，即每个结点的数据都是严格按事务的发起顺序生效的。

ZooKeeper 是如何保证事务顺序的呢？

这里需要了解下它的事务 ID，即 ZXID。ZooKeeper 通过比较各结点的 ZXID 和机器 ID 选出新的主结点。ZXID 由 Leader 节点生成，有新写入事件时，Leader 生成新 ZXID 并随提案一起广播，每个结点本地都保存了当前最近一次事务的 ZXID，ZXID 是递增的，所以谁的 ZXID 越大，就表示谁的数据是最新的。

ZXID 的生成规则如下图所示：

 ZXID 由两部分组成：

• 任期：完成本次选举后，直到下次选举前，由同一 Leader 负责协调写入；
• 事务计数器：单调递增，每生效一次写入，计数器加一。

ZXID 的低 32 位是计数器，所以同一任期内，ZXID 是连续的，每个结点又都保存着自身最新生效的 ZXID，通过对比新提案的 ZXID 与自身最新 ZXID 是否相差“1”，来保证事务严格按照顺序生效的。

ZooKeeper 集群的写入是由 Leader 结点协调的，真实场景下写入会有一定的并发量，那 Zab 协议的两阶段提交是如何保证事务严格按顺序生效的呢？Leader 在收到半数以上 ACK 后会将提案生效并广播给所有 Follower 结点，Leader 为了保证提案按 ZXID 顺序生效，使用了一个 ConcurrentHashMap，记录所有未提交的提案，命名为 outstandingProposals，key 为 ZXID，Value 为提案的信息。对 outstandingProposals 的访问逻辑如下：

• 每发起一个提案，会将提案的 ZXID 和内容放到 outstandingProposals 中，作为待提交的提案；
• 收到 Follower 的 ACK 信息后，根据 ACK 中的 ZXID 从 outstandingProposals 中找到对应的提案，对 ACK 计数；
• 执行 tryToCommit 尝试将提案提交，判断流程是，先判断当前 ZXID 之前是否还有未提交提案，如果有，当前提案暂时不能提交；再判断提案是否收到半数以上 ACK，如果达到半数则可以提交；如果可以提交，将当前 ZXID 从 outstandingProposals 中清除并向 Followers 广播提交当前提案；

Leader 是如何判断当前 ZXID 之前是否还有未提交提案的呢？由于前提是保证顺序提交的，所以 Leader 只需判断 outstandingProposals 里，当前 ZXID 的前一个 ZXID 是否存在。代码如下：

所以 ZooKeeper 是通过两阶段提交保证数据的最终一致性，并且通过严格按照 ZXID 的顺序生效提案保证其顺序一致性的。

以上就是今天的内容，希望对你有所帮助。