1.结论：

Zookeeper实现了A可用性、P分区容错性、C中的写入强一致性，丧失的是C中的读取一致性，读取准确地说是顺序一致性
主要有以下三点：

从一个读写请求分析，保证了可用性（不用阻塞等待全部follwer同步完成），保证不了数据的一致性，所以是ap。
从zk架构分析，zk在leader选举期间，会暂停对外提供服务（为啥会暂停，因为zk依赖leader来保证数据一致性)，所以丢失了可用性，保证了一致性。
进一步讲：这个c不是强一致性，而是最终一致性。即上面的写案例，数据最终会同步到一致，只是时间问题。

2.Zookeeper写入流程

首先client向zk Server发出一个写的请求，如果当前server不是Leader，那会把请求发送给Leader；
Leader接收到以后开始发起Proposal到Follwer，不对Observer发送；
Follower收到来自Leader的提议后，会返回ack响应；
Leader收到ack请求后，会采用过半机制，即发送出去的提议有一半以上的ack响应，则就会发送commit提交数据，同时也会向Observer提交commit；
返回给客户端写入成功的回应；
若有新的服务器加入进来，也会对Leader进行数据同步，来达到集群中数据的一致性。

3.Zookeeper读取流程

Client 向Zookeeper 发出读请求之后，无论请求的是Leader 还是 Follower ，都将会直接返回结果，如果使用sync读取，异步的实现当前进程与leader之间的指定path的数据同步，这样能读到最新的数据。

4.Zookeeper会脏读吗？

会的，如果一个zk集群有10000台节点，当进行写入的时候，如果已经有6K个节点写入成功，zk就认为本次写请求成功。但是这时候如果一个客户端读取的刚好是另外4K个节点的数据，那么读取到的就是旧的过期数据。

ZooKeeper并不保证在每个实例中，两个不同的客户端将具有相同的ZooKeeper数据的视图。由于诸如网络延迟的因素，一个客户端可以在另一客户端被通知该改变之前执行更新，考虑两个客户端A和B的场景。如果客户端A将znode / a的值从0设置为1，则告诉客户端B读取/ a，则客户端B可以读取旧值0，这取决于它连接到的服务器。如果客户端A和客户端B读取相同的值很重要，则客户端B应该在执行读取之前从ZooKeeper API方法调用sync()方法。

5.几种一致性解读

强一致性:又称线性一致性(linearizability )

任意时刻，所有节点中的数据是一样的,
一个集群需要对外部提供强一致性，所以只要集群内部某一台服务器的数据发生了改变，那么就需要等待集群内其他服务器的数据同步完成后，才能正常的对外提供服务
保证了强一致性，务必会损耗可用性

弱一致性:

系统中的某个数据被更新后，后续对该数据的读取操作可能得到更新后的值，也可能是更改前的值。
即使过了不一致时间窗口，后续的读取也不一定能保证一致。

最终一致性:

弱一致性的特殊形式,不保证在任意时刻任意节点上的同一份数据都是相同的，但是随着时间的迁移，不同节点上的同一份数据总是在向趋同的方向变化
存储系统保证在没有新的更新的条件下，最终所有的访问都是最后更新的值

顺序一致性:

任何一次读都能读到某个数据的最近一次写的数据。
系统的所有进程的顺序一致，而且是合理的。即不需要和全局时钟下的顺序一致，错的话一起错，对的话一起对(目前网上能查到的原话);前三种应该都好理解。强一致性就是在任意时刻，所有节点中的数据都是一样的。

弱一致性就是可能访问的到更新后的值,也可能访问不到。

最终一致性,不保证任何节点都是相同的,也就是说各节点的数据版本可能完全是混乱的,a节点是1,b节点是2,c节点是3,然后a节点更新到2,b节点更新到3,但能保证在没有更新后达成一致。

Java内存模型中顺序一致性,如果对多线程并发有理解,可以结合下来理解顺序一致性内存模型是一个被计算机科学家理想化了的理论参考模型，它为程序员提供了极强的内存可见性保证。顺序一致性内存模型有两大特性：

一个线程中的所有操作必须按照程序的顺序来执行。
（不管程序是否同步）所有线程都只能看到一个单一的操作执行顺序。在顺序一致性内存模型中，每个操作都必须原子执行且立刻对所有线程可见。

这里的顺序一致性,讲的是一种多线程并发执行下理想情况,包含两种要求：

线程中的操作必须按照程序的顺序执行,也就是说,不能自己自作主张,更换执行顺序
线程中的操作是原子性的,执行了就是执行了,没执行就是没执行,不存在中间状态,而且一旦执行,其他变量应该立刻可见。

联系到zookeeper,说点结论：

各节点的数据更新必须按照顺序进行。
数据写入执行情况,数据版本应对其他节点可见(leader能知道写入是否成功)。

结合以上,你会发现,zookeeper并不是最终一致性,而是顺序一致性。

最终一致性的特点是,无法保证任意节点在同一时间某份数据是相同的,但是最终在没有新的更新时会达成一致。而Zookeeper所有节点的数据版本都是递增的,可能会有某个节点因故障版本低于大多数,但是是有序的,不会出现各自增长的情况。

比如,Zookeeper节点可能会出现4台数据是version 5,一台数据是version4。但是不会是5台机器各自更新。

所以这里对顺序一致性的定义是

任何一次读都能读到某个数据的最近一次写的数据。
对其他节点之前的修改是可见(已同步)且确定的,并且新的写入建立在已经达成同步的基础上。

Zookeeper到底是AP还是CP？相关推荐

服务注册中心AP和CP区别【Nacos|Eureka|Consul|Zookeeper】
当下,分布式系统正变得越来越重要,大型网站几乎都是分布式的.分布式系统的最大难点,就是各个节点的状态如何同步.CAP 定理是这方面的基本定理,也是理解分布式系统的起点. CAP定理,又被称作布鲁尔定理 ...
Nacos 的AP和CP模式
Nacos是阿里开源的,Nacos 支持基于 DNS 和基于 RPC 的服务发现.在Spring Cloud中使用Nacos,只需要先下载 Nacos 并启动 Nacos server,Nacos只需 ...
Nacos 是如何同时实现AP与CP的
Nacos 是如何同时实现AP与CP的两种一致性策略如何在nacos中共存 AP实现 CP实现重要的协议--RAFT nacos是如何实现CP(raft)的为什么要同时实现CP和AP两套一致性策 ...
AUTOSAR AP与 CP 有什么差异？
1标准概况不同 1.1 时间在2003年AUTOSAR组织刚成立的时候,只有一个AUTOSAR标准,没有AP(Adaptive Platform)与CP(Classic Platform)之分. 在 ...
Autosar AP – AP和CP差异
■ 硬件: 1. 芯片类型: ▪ CP AUTOSAR一般运行在8bit.16bit.32bit的微控制器(MCU)中,如英飞凌的TC3xx,瑞萨的RH850等. ▪ AP AUTOSAR可以运行在6 ...
Nacos中服务注册中心AP、CP模式实现，AP、CP模式切换
本文分析Nacos基于Nacos 2.0 Nacos中服务注册中心默认是AP模式,如果设置为CP模式那么客户端设置 spring.cloud.nacos.discovery.ephemeral=fa ...
Nacos中AP和CP模式如何切换
CAP理论这个定理的内容是指的是在一个分布式系统中.Consistency(一致性). Availability(可用性).Partition tolerance(分区容错性),三者不可得兼. 一致 ...
SpringCloudAlibaba--Nacos作为服务注册中心、各种注册中心对比、Nacos的AP和CP模式切换
基于Nacos的服务提供者创建cloudalibaba-provider-payment9001模拟支付模块: 依赖: <?xml version="1.0" encodi ...
分析zookeeper到底能做什么？
Zookeeper是hadoop的一个子项目,虽然源自hadoop,但是我发现zookeeper脱离hadoop的范畴开发分布式框架的运用越来越多.今天我想谈谈zookeeper,本文不谈如何使用zo ...

Zookeeper到底是AP还是CP？