一致性的定义
最终一致性
最终一致性，是BASE理论提出来的，好多系统分布式系统为了强调可用性，从而弱化一致性，通过最终一致性来满足，那多长时间能达到最终一致呢，这就有一个不一致的时间窗口(Inconsistency Window)。
顺序一致性
顺序一致性是保证下次读到的值，肯定不会比本次读到的版本要旧，即，肯定读到新的值。
Zookeeper 一致性的精确定义
zookeeper 是一个顺序一致性的实现，zookeeper 保证不会读到比上次更老的版本，因为zookeeper client 会携带一个事物id，如果链接断开，连上了没有同步的那台机器，这台server 会比较客户端当前携带的事物id,如果大于，则会和leader 同步。顺序一致性的解释和原理，请看饿了么的团队写的文章：https://mp.weixin.qq.com/s/4NtdY6nEBi173Ya4yHWy2g
Zookeeper 多数据中心部署
现在满多互联网公司说实现多活，多活面临的一个基本问题是，服务协调和通信而且是在跨地域跨数据中心的情况下，解决网络延迟和数据一致的问题，下面我们看下zookeeper 跨多Data Center 部署方案
单个zookeeper 集群
单个集群即zookeeper的acceptor节点部署在多个区域，保证数据一致性。
则种部署方式能完全保证可用性，不回出现单点，但是在commit 投票时，都需要跨地域操作，不可避免的要面对网络延迟和带宽的开销，即更新操作就比较慢了，想想假如在北京和上海两个数据中心，更新操作commit 投票时一个请求就要30ms的延迟。
Acceptors 和 learner 分开部署
这种部署方式是acceptor 部署在一个集群负责投票和选举。learner 分别部署在其他的数据中心，负责同步数据，这样能减少更新操作时的网络延迟，因为都在一个数据中心通信，网络和带宽没有问题，但是写吞吐量受到了单个Acceptors集群的限制，在远程数据中心的更新回有很大的延迟，以及还有单点问题。
多个zookeeper 集群
这种模式是一个地区一个zookeeper集群，learner分别部署在异地， 比如上海和北京都部署一个，上海的zookeeper 集群的learner 部署在北京，北京的learner部署在上海，这种部署的方式的好处是多个数据中心可以并行处理请求，吞吐量高，而且一个数据中心出现故障，其他的不回受影响，单是这种方案有一个一致性的问题，在并发更新而且从异地数据中心读另外一个更新的数据时，
多zookeeper 集群 而且保证一致性的方案
Modular composition
基于上面三种方案的优缺点，Modular Composition of Coordination Services 这篇论文提供了一个解决方案，他们对zookeeper 的server 端的一个组件commit processor做了修改，并提供了一个waper的client ，并且提供了batch for zookeeper，zookeeper社区在3.6版本回合并进来，主要实现如下两个关键改进：
服务端
服务端通过隔离每个客户端的请求，来增加吞吐量，目前zookeeper的commit processor 实现是为所有的客户端请求维持一个队列，这样不同的客户端更新也有等前面的请求完成2PC后才能进入后面的处理。
客户端
客户端通过对zk client的包装，可以链接多个zookeeper 集群，具体请参考相关的论文。
总结
zookeeper 多数据中心部署方案的比较
| 方案 | 写性能 | 读性能 | 一致性语义 | 可用性写 | 可用性读 |
|---|---|---|---|---|---|
| 单个zookeeper集群 | 非常慢 | 快 | 正确 | 大多数 | 所有节点 |
| Learners 方案 | 慢 | 快 | 正确 | Acceptors | 所有节点 |
| 多个zookeeper集群 | 快 | 快 | 回出现不一致 | Local | 所有节点 |
| 改造方案 | 快 | 快 | 正确 | Local | Local |
