- 什么是强一致性 -
说到zab到底是强一致性，还是最终一致性，相信大家一定能搜到大量互相打架的文章。在评判这个问题前，咱们在回顾下Consistency(一致性)、Consensus(共识)。这两者间的关系如下：
共识是一种数据同步过程，一致性是数据同步状态。所以一致性包含了共识。
林淮川，公众号：川聊架构分布式架构设计篇(十三)-一致性算法概述
Consistent, Available, Partition-Tolerant Web
Services》中看到两者的关系。在论文中我们可以清晰的看到 CAP关于一致性的完整称呼叫"Atomic Consistency"，即原子一致性：原子一致性是针对单个请求/响应操作序列的属性，而数据库一致性是事务的组成，包含了数据库概念中一致性和原子性。
在数据库中，为了提高数据库对外性能，通常采用写MVCC等。而且生产实践中，我们通常认为数据库是强一致性的，而数据库的隔离级别通常默认是RC注1，存在幻读等并发控制问题。
注1：MySQL的RR其实是利用MVCC + RC来实现。
综上所述，我们可以知道强一致性具有一定的模糊性和习惯性，因此我们可以认为强一致性是一种统称，那么我们怎么判断强一致性和最终一致性呢？这需要我们通过场景来实际分析。
- ZooKeeper 一致性保证 -
顺序一致性：来自客户端的更新将按照发送的顺序被写入到ZooKeeper。
原子性：更新操作要么成功，要么失败，没有中间状态。
单系统快照：客户端将看到相同的服务视图，而不管它连接到哪个服务器。
可靠性：一旦应用更新，数据将被持久化，直到数据被再次更新，这种保证有两个推论：
如果客户端得到了成功的返回码，说明写入成功，数据被持久化，如果出现了通信错误，超时等一些故障，客户端将不知道更新是否已应用。ZooKeeper采取措施将失败降至最低，但唯一的保证是只有成功的返回代码。（这在Paxos中称为单调性条件。）
从服务器故障中恢复时，客户端通过读取请求或成功更新看到的任何更新将永远不会回滚。
及时性：在一段时间后，客户端将看到最新的系统更新，在此期间客户端将看到这种变更。
- ZooKeeper 的一致性确定 -
线性写：为了保证写的一致性，使用回主写实现了写的串行化
过半写入：为了追求写入的性能，使用过半写入+拜占庭机制保障写入数据的有效性。
顺序读：在读取的情况下，ZooKeeper可以提供较旧的数据，但由于写入的有序，可以保证节点在生命周期中对外的数据一致性。
ZAB的算法在并发控制中：如果读取请求与写入请求并发，未参与过半写入的节点对外提供的数据可能是历史数据，造成了客户端的读取不一致性，新增加了这个级别的并发控制现象。
从 章节一 我们也知道 ，不管是传统数据库，还是线性一致性都存在一定的并发控制问题，所以是否可以认为并发控制的隔离性是可以接受一定的可损性？我们在从一些案例来ZooKeeper到底是强一致性的CP，还是最终一致性的AP：
在分布式锁场景：我们利用ZooKeeper的写临时顺序节点+watch机制实现了抢锁的串行化，保证了锁的唯一性。在这里面我们用到了写一致，但是没用到读一致，这时ZooKeeper是CP。
在注册中心场景：ZooKeeper在选举leader时，会停止服务，直到选举成功之后才会再次对外提供服务。这时ZooKeeper是优先保证一致性的前提下，才会顾及到可用性，这时ZooKeeper是CP。
- 作者介绍 -
毕业于西安交通大学；奈学教育首席架构师，教学教研负责人；前大树金融高级架构师、技术委员会开创者、技术总监；前天阳宏业交易事业部技术主管；多年互联网金融行业（ToB）经验。
