弄到一份宝藏级SpringCloud实战文档，泪目
两个要求：
- 任何一次读都能读到某个数据的最近一次写的数据。
- 系统的所有进程的顺序一致，而且是合理的。即不需要和全局时钟下的顺序一致，错的话一起错，对的话一起对。
举个例子：
Write(x, 4)：写入x=4?
Read(x, 0)：读出x=0
1）图a是满足顺序一致性，但是不满足强一致性的。原因在于，从全局时钟的观点来看，P2进程对变量X的读操作在P1进程对变量X的写操作之后，然而读出来的却是旧的数据。但是这个图却是满足顺序一致性的，因为两个进程P1，P2的一致性并没有冲突。从这两个进程的角度来看，顺序应该是这样的：Write(y,2) , Read(x,0) , Write(x,4), Read(y,2)，每个进程内部的读写顺序都是合理的，但是这个顺序与全局时钟下看到的顺序并不一样。
2）图b满足强一致性，因为每个读操作都读到了该变量的最新写的结果，同时两个进程看到的操作顺序与全局时钟的顺序一样，都是Write(y,2) ,Write(x,4), Read(x,4) ,? Read(y,2)。
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”或一致性），则可序列化执行也保持正确性。因此，可串行化是一种保证数据库正确性的机制。
与线性化不同，可串行化本身不会对事务的排序施加任何实时约束。可序列化也是不可组合的。可串行化并不意味着任何类型的确定性顺序 - 它只需要存在一些等效的串行执行。
这些定义如此混乱的原因之一是线性化来自分布式系统和并发编程社区，可串行化来自数据库社区。如今，几乎每个人都使用分布式系统和数据库，这往往会导致过载的术语（例如，“一致性”，“原子”）。
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、 结论
可以的出的结论是Zookeeper的一致性保证的是单调一致性，CAP原则中的C是强一致性。
最后
对于很多Java工程师而言，想要提升技能，往往是自己摸索成长，不成体系的学习效果低效漫长且无助。
整理的这些资料希望对Java开发的朋友们有所参考以及少走弯路，本文的重点是你有没有收获与成长，其余的都不重要，希望读者们能谨记这一点。
再分享一波我的Java面试真题+视频学习详解+技能进阶书籍
CodeChina开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频】