来自：架构之美

ZooKeeper作为分布式应用系统协调服务，在分布式系统中的应用非常广泛，在某些业务场景下甚至可以作为注册中心、分布式锁来使用。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的访问逻辑如下：

1、每发起一个提案，会将提案的ZXID和内容放到outstandingProposals中，作为待提交的提案；

2、收到Follower的ACK信息后，根据ACK中的ZXID从outstandingProposals中找到对应的提案，对ACK计数；

3、执行tryToCommit尝试将提案提交，判断流程如下：

3.1：判断当前ZXID之前是否还有未提交提案，如果有，当前提案暂时不能提交；

3.2：判断提案是否收到半数以上ACK，如果达到半数则可以提交；

3.3：如果可以提交，将当前ZXID从outstandingProposals中清除并向Followers广播提交当前提案；

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

图三

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

特别推荐一个分享架构+算法的优质内容，还没关注的小伙伴，可以长按关注一下：

长按订阅更多精彩▼如有收获，点个在看，诚挚感谢