一文详解ZooKeeper的顺序一致性

ZooKeeper是一个分布式的协调服务，它提供了高可用性和顺序一致性的数据存储，通常用于解决分布式系统中的协调问题。ZooKeeper通过使用ZooKeeper客户端库与ZooKeeper服务器集群进行交互来实现这些特性。

ZooKeeper保证事务的顺序一致性是通过原子更新操作的方式来实现的。ZooKeeper提供了一组原子操作，可以让客户端更新服务器上的数据节点。这些原子操作被称为 ZooKeeper事务，事务在服务器端被逐个处理，并按照它们在客户端发送的顺序来执行。这确保了所有客户端看到的数据更新顺序是一致的。

ZooKeeper 的设计目标之一是提供一致性服务，因此在其内部实现中，保持事务的顺序一致性非常重要。

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的顺序生效提案保证其顺序一致性的。