1.zookeeper是cp还是ap
zookeeper保证的是cp，eruka是ap。
准确来说zookeeper保证的是写是强一致性，读是顺序一致性。
2.那么什么是强一致性，什么是顺序一致性
2.1强一致性:又称线性一致性(linearizability)
- 任意时刻，所有节点中的数据是一样的,
- 一个集群需要对外部提供强一致性，所以只要集群内部某一台服务器的数据发生了改变，那么就需要等待集群内其他服务器的数据同步完成后，才能正常的对外提供服务
- 保证了强一致性，务必会损耗可用性
2.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将事务日志中尚未提交的消息进行处理
本文转载自: https://blog.csdn.net/weixin_43854800/article/details/127983835
版权归原作者 白云踏浪 所有， 如有侵权，请联系我们删除。
版权归原作者 白云踏浪 所有， 如有侵权，请联系我们删除。