关于分布式系统一致性级别的划分，有些文章划分为强一致性，顺序一致性以及弱一致性。
最终一致性属于弱一致性，最终一致性根据更新数据后各进程访问到数据的时间和方式的不同划分为：
因果一致性、
“读己之所写（read-your-writes）”一致性、
会话（Session）一致性、
单调（Monotonic）读一致性、
单调写一致性
另一种，根据一致性的强弱程度不同，直接划分为强一致性、单调一致性、会话一致性、最终一致性和弱一致性。
最终一致性和顺序一致性的区别最终一致性和顺序一致性的差别非常大。
顺序一致性是更强的一致性模型，最终一致性模型是非常弱的一致性模型。可以这么说，满足顺序一致性的系统一定满足最终一致性，但满足最终一致性的系统不一定满足顺序一致性。比如，zookeeper是顺序一致性，zookeeper也满足最终一致性；cassandra是最终一致性，但cassandra不满足顺序一致性。
ZK一致性级别分析博文《线性一致性(Linearizability)是并发控制的基础》中提到【在分布式领域中，我们也会说线性一致性，例如Zookeeper是线性一致性的，再比如分布式领域著名的CAP定理中的C，也是指线性一致性。】
作者的意思是他在文章中提到的【Zookeeper是线性一致性的】是为了举例说明线性一致性也会用来描述分布式系统，因为线性一致性最早在并行计算领域提出。
其实，各个领域的线性一致性都是一样的。线性一致性最早在并行计算领域提出，现在在分布式领域、数据库领域都在用，含义是一样的。我们可以把线性一致性称作为强一致性，或者原子一致性。准确的来说，Zookeeper如果只有写请求时，是线性一致性的；如果从读和写的角度来说是顺序一致性的。
zookeeper是不是线性一致性呢作者是这样解释的：【Zookeeper如果只有写请求时，是线性一致性的；如果从读和写的角度来说是顺序一致性的】
Zookeeper保证哪种级别的一致性正如上面所说，Zookeeper如果只有写请求时，是线性一致性的；如果从读和写的角度来说是顺序一致性的。
如何理解Zookeeper的顺序一致性请参看 https://juejin.im/post/5d5a2aa6f265da03b2153816
ZK的单调一致性分析根据 Zookeeper 的 ZAB 协议来看，ZK 保证的一致性是单调一致性（任何时刻，任何用户一旦读到某个数据在某次更新后的值，那么就不会再读到比这个值更旧的值。也就是说，获取的数据顺序必是单调递增的。）
原因：
假设有2n+1个server，在同步流程中，leader 向 follower 同步数据，当同步完成的 follower 数量大于 n+1时同步流程结束，系统可接受 client 的连接请求。如果client 连接的并非同步完成的follower，那么得到的并非最新数据，但可以保证单调性。
假设是 follower 接收的写请求，然后转发给 leader 处理；leader 完成两阶段提交的机制。向所有 server 发起提案，当提案获得超过半数（n+1）的 server 认同后，将对整个集群进行同步，超过半数（n+1）的 server 同步完成后，该写请求完成。如果 client 连接的并非同步完成 follower，那么得到的并非最新数据，但可以保证单调性。
用分布式系统的CAP原则来分析Zookeeper（1）C（一致性）: Zookeeper保证了顺序一致性（满足最终一致性），在十几秒可以Sync到各个节点
（2）A（可用性）: Zookeeper保证了可用性，数据总是可用的（没有锁）。并且有一大半的节点所拥有的数据是最新的、实时的。 如果想保证取得是数据一定是最新的，需要手工调用Sync()
（3）P（分区容错性）: 有两点需要分析
节点多了会导致写数据延时变大，因为更多的节点需要同步
节点多了Leader选举耗时变长，从而会放大网络的问题， 可以通过引入 observer（不参与选举）节点缓解这个问题.