zookeeper怎么保证一致性的(ZAB协议)

今天阿里来电话面试，我刚睡醒，还特别懵就去电话面试了，我是完了，但是最不可原谅的问题是这么简单的问题我怎么没想起来？这么简单的问题，唉，看来秋招是不用想了，等毕业几年再试试吧？

怎么保证的一致性，是依赖了ZAB协议

解释：ZAB协议是伪分布式协调服务Zookeeper专门设计的一种崩溃恢复的原子广播协议，

两种基本的模式：

1. 崩溃恢复
2. 消息广播

这两个模式是相辅相成的
消息广播模式就是zookeeper不出现任何问题，并且正常工作的模式，
崩溃恢复看字面意思就是当zookeeper 出现故障时用于恢复的，

下面说说当出现故障时这两种模式怎么用的吧？(不故障时就一种没必要说)

当整个zookeeper集群刚刚启动或者Leader服务器宕机、重启或者网络故障导致不存在过半的服务器与Leader服务器保持正常通信时(Leader选举，必须要存在过半的服务器)，
所有进程（服务器）进入崩溃恢复模式，首先选举产生新的Leader服务器，然后集群中Follower服务器开始与新的Leader服务器进行数据同步，当集群中超过半数机器与该Leader服务器完成数据同步之后，退出恢复模式进入消息广播模式，Leader服务器开始接收客户端的事务请求生成事物提案来进行事务请求处理。

上面说了ZAB协议在zookeeper的作用，下面来看看ZAB协议到底是什么

Zab协议是Zookeeper保证数据一致性的核心算法，Zab借鉴了Paxos算法，但又不像Paxos那样，是一种通用的分布式一致性算法，基于该协议，zk实现了一种主备模型（即Leader和Follower模型），保证了事务的最终一致性

定义了事务请求的处理方式（借的别人的图）

1. 首先客户端所有的写请求都由一个Leader接收，而其余的都是Follower(从者)
2. Leader 负责将一个客户端事务请求，转换成一个 事务Proposal，并将该 Proposal 分发给集群中所有的 Follower(备份) ，也就是向所有 Follower 节点发送数据广播请求（或数据复制）记住这里发送给的不光是数据本身，还有其他的，相当于包装
3. 分发之后Leader需要等待所有Follower的反馈（Ack请求），在Zab协议中，只要超过半数的Follower进行了正确的反馈后（也就是收到半数以上的Follower的Ack请求），那么 Leader 就会再次向所有的 Follower发送 Commit 消息，要求其将上一个 事务proposal 进行提交。就是相当于通过，如果是用dubbo进行微服务就是zookeeper这个协调服务通过了，开始往服务端发送数据

这就是典型的2PC(二阶提交)
关于二阶段提交和三阶段提交可以参考https://www.cnblogs.com/huangjuncong/p/8338448.html里面还有关于Paxos算法的内容

ZAB协议的原理

1. 发现：必须有一个Leader，而Leader拥有一个Follower的列表，里面是可以通讯的Follower，为后面的同步，广播做准备
2. 同步：Leader 要负责将本身的数据与 Follower 完成同步，做到多副本存储。这样也是提现了CAP中的高可用和分区容错。Follower将队列中未处理完的请求消费完成后，写入本地事务日志中
3. 广播：Leader 可以接受客户端新的事务Proposal请求，将新的Proposal请求广播给所有的 Follower。