分布式系统的一致性级别划分及 Zookeeper 一致性级别分析

3）图 c 不满足顺序一致性，当然也就不满足强一致性了。因为从进程 P1 的角度看，它对变量 Y 的读操作返回了结果 0。那么就是说，P1 进程的对变量 Y 的读操作在 P2 进程对变量 Y 的写操作之前，这意味着它认为的顺序是这样的：Write(x,4) , Read(y,0) , Write(y,2), Read(x,0)，显然这个顺序又是不能被满足的，因为最后一个对变量 x 的读操作读出来也是旧的数据。因此这个顺序是有冲突的，不满足顺序一致性。

1.3 弱一致性

数据更新后，如果能容忍后续的访问只能访问到部分或者全部访问不到，则是弱一致性。

最终一致性就属于弱一致性。

最终一致性

不保证在任意时刻任意节点上的同一份数据都是相同的，但是随着时间的迁移，不同节点上的同一份数据总是在向趋同的方向变化。

简单说，就是在一段时间后，节点间的数据会最终达到一致状态。

最终一致性根据更新数据后各进程访问到数据的时间和方式的不同，又可以区分为：

因果一致性（Casual Consistency）。如果进程 A 通知进程 B 它已更新了一个数据项，那么进程 B 的后续访问将返回更新后的值，且一次写入将保证取代前一次写入。与进程 A 无因果关系的进程 C 的访问，遵守一般的最终一致性规则。

**“读己之所写（read-your-writes）”一致性。**当进程 A 自己更新一个数据项之后，它总是访问到更新过的值，绝不会看到旧值。这是因果一致性模型的一个特例。

**会话（Session）一致性。**这是上一个模型的实用版本，它把访问存储系统的进程放到会话的上下文中。只要会话还存在，系统就保证“读己之所写”一致性。如果由于某些失败情形令会话终止，就要建立新的会话，而且系统的保证不会延续到新的会话。

**单调（Monotonic）读一致性。**如果进程已经看到过数据对象的某个值，那么任何后续访问都不会返回在那个值之前的值。

**单调写一致性。**系统保证来自同一个进程的写操作顺序执行。要是系统不能保证这种程度的一致性，就非常难以编程了。

另外一种划分一致性级别的：

一致性是指从系统外部读取系统内部的数据时，在一定约束条件下相同，即数据变动在系统内部各节点应该是同步的。根据一致性的强弱程度不同，可以将一致性级别分为如下几种：

**　　①强一致性（strong consistency）。任何时刻，任何用户都能读取到最近一次成功更新的数据。**　　②单调一致性（monotonic consistency）。任何时刻，任何用户一旦读到某个数据在某次更新后的值，那么就不会再读到比这个值更旧的值。也就是说，获取的数据顺序必是单调递增的。**　　③会话一致性（session consistency）。任何用户在某次会话中，一旦读到某个数据在某次更新后的值，那么在本次会话中就不会再读到比这值更旧的值。会话一致性是在单调一致性的基础上进一步放松约束，只保证单个用户单个会话内的单调性，在不同用户或同一用户不同会话间则没有保障。示例 case：php 的 session 概念。**　　④?最终一致性（eventual consistency）。用户只能读到某次更新后的值，但系统保证数据将最终达到完全一致的状态，只是所需时间不能保障。**　　⑤**弱一致性（weak consistency）。用户无法在确定时间内读到最新更新的值。

2. 共识（Consensus)

共识问题中所有的节点要最终达成共识，由于最终目标是所有节点都要达成一致，所以根本不存在一致性强弱之分。

例如，Paxos 是共识（Consensus）算法而不是强一致性（Consistency）协议。共识算法没有一致性级别的区分。

3.线性化和可串行化的区别

读写操作的线性化与术语“原子一致性”同义，并且是 Gilbert 和 Lynch?对 CAP 定理的证明中的?“C”或“一致性”?。我们说线性化是可组合的?（或“本地”），因为如果系统中每个对象的操作是可线性化的，那么系统中的所有操作都是可线性化的。

可串行性是 ACID 中的传统“I”或隔离。如果用户的事务各自保持应用程序的正确性（ACID 中的“C”或一致性），则可序列化执行也保持正确性。因此，可串行化是一种保证数据库正确性的机制。

与线性化不同，可串行化本身不会对事务的排序施加任何实时约束。可序列化也是不可组合的。可串行化并不意味着任何类型的确定性顺序 - 它只需要存在一些等效

【一线大厂Java面试题解析+核心总结学习笔记+最新架构讲解视频+实战项目源码讲义】
浏览器打开：qq.cn.hn/FTf 免费领取

的串行执行。

这些定义如此混乱的原因之一是线性化来自分布式系统和并发编程社区，可串行化来自数据库社区。如今，几乎每个人都使用分布式系统和数据库，这往往会导致过载的术语（例如，“一致性”，“原子”）。

4、zookeeper 的一致性分析-单调一致性

很多文章和博客里提到，zookeeper 是一种提供强一致性的服务，在分区容错性和可用性上做了一定折中，这和 CAP 理论是吻合的。但实际上 Zookeeper 提供的只是单调一致性。原因：1. 假设有 2n+1 个 server，在同步流程中，leader 向 follower 同步数据，当同步完成的 follower 数量大于 n+1 时同步流程结束，系统可接受 client 的连接请求。如果 client 连接的并非同步完成的 follower，那么得到的并非最新数据，但可以保证单调性，也就是说，可获取的数据顺序是单调递增的。2. 假设是 follower 接收到的写请求，则会转发给 leader 处理；leader 完成两阶段提交的机制。向所有 server 发起提案，当提案获得超过半数（n+1）的 server 的 ACK 后，将对整个集群进行同步，超过半数（n+1）的 server 同步完成后，该写请求完成。如果 client 连接的并非同步完成 follower，那么得到的并非最新数据，但可以保证单调性，也就是说，可获取的数据顺序是单调递增的。

用分布式系统的 CAP 原则来分析 Zookeeper：（1）C: Zookeeper 保证了最终一致性,在十几秒可以 Sync 到各个节点（2）A: Zookeeper 保证了可用性,数据总是可用的,没有锁.并且有一大半的节点所拥有的数据是最新的,实时的. 如果想保证取得是数据一定是最新的,需要手工调用 Sync()（3）P: 有 2 点需要分析的

• 节点多了会导致写数据延时非常大,因为需要多个节点同步.

• 节点多了 Leader 选举非常耗时, 就会放大网络的问题. 可以通过引入 observer 节点缓解这个问题.

5、 结论