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