在讲顺序一致性之前，咱们思考一个问题，假如说zookeeper是一个最终一致性模型，那么他会发生什么情况
ClientA/B/C假设只串行执行， clientA更新zookeeper上的一个值x。ClientB和clientC分别读取集群的不同副本，返回的x的值是不一样的。clientC的读取操作是发生在clientB之后，但是却读到了过期的值。很明显，这是一种弱一致模型。如果用它来实现锁机制是有问题的。
顺序一致性提供了更强的一致性保证，我们来观察下面这个图，从时间轴来看，B0发生在A0之前，读取的值是0，B2发生在A0之后，读取到的x的值为1.而读操作B1/C0/C1和写操作A0在时间轴上有重叠，因此他们可能读到旧的值为0，也可能读到新的值1. 但是在强顺序一致性模型，
如果B1得到的x的值为1，那么C1看到的值也一定是1.
需要注意的是：由于网络的延迟以及系统本身执行请求的不确定性，会导致请求发起的早的客户端不一定会在服务端执行得早。最终以服务端执行的结果为准。
简单来说：顺序一致性是针对单个操作，单个数据对象。属于CAP中C这个范畴。一个数据被更新后，能够立马被后续的读操作读到。
但是zookeeper的顺序一致性实现是缩水版的，在下面这个网页中，可以看到官网对于一致性这块做了解释 http://zookeeper.apache.org/doc/r3.5.5/zookeeperProgrammers.html#ch_zkGuarantees zookeeper不保证在每个实例中，两个不同的客户端具有相同的zookeeper数据视图，由于网络延迟等因素，一个客户端可能会在另外一个客户端收到更改通知之前执行更新，考虑到2个客户端A和B的场景，如果A把znode /a的值从0设置为1，然后告诉客户端B读取 /a， 则客户端B可能会读取到旧的值0，具体取决于他连接到那个服务器，如果客户端A和B要读取必须要读取到相同的值，那么client B在读取操作之前执行sync方法。
除此之外，zookeeper基于zxid以及阻塞队列的方式来实现请求的顺序一致性。如果一个client连接到一个最新的follower上，那么它read读取到了最新的数据，然后client由于网络原因重新连接到zookeeper节点，而这个时候连接到一个还没有完成数据同步的follower节点，那么这一次读到的数据不久是旧的数据吗？实际上zookeeper处理了这种情况，client会记录自己已经读取到的最大的zxid，如果client重连到server发现client的zxid比自己大。连接会失败