zookeeper是cp还是ap

1.zookeeper是cp还是ap

zookeeper保证的是cp，eruka是ap。

准确来说zookeeper保证的是写是强一致性，读是顺序一致性。

2.那么什么是强一致性，什么是顺序一致性

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

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

 2.2顺序一致性:

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

2.3为什么写是强一致性，读是顺序一致性

  zookeeper只有Leader节点能写数据，其他的Follower节点读数据；写的时候，保证只有Leader节点写完并同步完其他Follower节点，才会响应客户端，所以是写强一致性；

但是读的时候，Follower节点也可以提供服务，zookeeper是直接返回响应结果的；这个时候Follower节点可能还没同步主节点数据，对于同一个节点数据zookeeper是按版本号记录的，那么这个时候就会返回该节点最新版本号的数据，所以读取是顺序一致性；

3.在Zookeeper中，主要依赖ZAB协议来实现分布式数据一致性

3.1 ZAB协议分为两部分：

• 消息广播
• 崩溃恢复 

3.2 消息广播

        Zookeeper使用单一的主进程Leader来接收和处理客户端所有事务请求，并采用ZAB协议的原子广播协议，将事务请求以Proposal提议广播到所有Follower节点，当集群中有过半的Follower服务器进行正确的ACK反馈，那么Leader就会再次向所有的Follower服务器发送commit消息，将此次提案进行提交。这个过程可以简称为2pc事务提交，整个流程可以参考下图，注意Observer节点只负责同步Leader数据，不参与2PC数据同步过程。

 

 

3.3 崩溃恢复

        在正常情况消息下广播能运行良好，但是一旦Leader服务器出现崩溃，或者由于网络原理导致Leader服务器失去了与过半Follower的通信，那么就会进入崩溃恢复模式，需要选举出一个新的Leader服务器。在这个过程中可能会出现两种数据不一致性的隐患，需要ZAB协议的特性进行避免。

• Leader服务器将消息commit发出后，立即崩溃
• Leader服务器刚提出proposal后，立即崩溃

ZAB协议的恢复模式使用了以下策略：

• 选举zxid最大的节点作为新的leader
• 新leader将事务日志中尚未提交的消息进行处理