一：ZooKeeper 概念
1.什么是zookeeper?
zookeeper是一个高可用的分布式管理和协调工具 是基于ZAB算法（原子消息广播协议）的框架能够很好的保证分布式环境中数据的一致性。也正是因为这种特性 使得Zookeeper成为了j解决分布式一致性问题的利器。
2.zookeeper的几大特性：
1.顺序一致性
2.原子性：客户端对任意一台zookeeper进程操作 zookeeper会同步到其他的其实上 不会出现部分机器修改了 而另外一些机器没有修改的情况出现
3.单一视图：无论客户端连接的是那一台机器 看到的数据都是一致的
4.可靠性 ：客户端发起一个请求 只要服务端给了反馈那么服务器的各个机器一定就同步一致的 除非出现一些网络原因 数据同步不过去 就会返回一个超时什么的返回给客户端。如果服务器挂掉半数以上就不提供服务了
5.实时性：客户端修改一个数据 那么就能立刻获取修改后的数据
3.ZAB算法（原子消息广播协议）
1.ZAB协议是专门为zookeeper实现分布式协调功能而设计。zookeeper主要是根据ZAB协议是实现分布式系统数据一致性。
2.zookeeper根据ZAB协议建立了主备模型完成zookeeper集群中数据的同步。这里所说的主备系统架构模型是指，在zookeeper集群中，只有一台leader负责处理外部客户端的事物请求(或写操作)，然后leader服务器将客户端的写操作数据同步到所有的follower节点中。
3.ZAB的协议核心是在整个zookeeper集群中只有一个节点即Leader将客户端的写操作转化为事物(或提议proposal)。Leader节点再数据写完之后，将向所有的follower节点发送数据广播请求(或数据复制)，等待所有的follower节点反馈。在ZAB协议中，只要超过半数follower节点反馈OK，Leader节点就会向所有的follower服务器发送commit消息。即将leader节点上的数据同步到follower节点之上。
4.ZAB协议中主要有两种模式，第一是消息广播模式；第二是崩溃恢复模式
四：消息广播模式：
1.在zookeeper集群中数据副本的传递策略就是采用消息广播模式。zookeeper中数据副本的同步方式与二阶段提交相似但是却又不同。二阶段提交的要求协调者必须等到所有的参与者全部反馈ACK确认消息后，再发送commit消息。要求所有的参与者要么全部成功要么全部失败。二阶段提交会产生严重阻塞问题。
2.ZAB协议中Leader等待follower的ACK反馈是指”只要半数以上的follower成功反馈即可，不需要收到全部follower反馈”
图中展示了消息广播的具体流程图
4.zookeeper中消息广播的具体步骤如下：
4.1. 客户端发起一个写操作请求
4.2. Leader服务器将客户端的request请求转化为事物proposql提案，同时为每个proposal分配一个全局唯一的ID，即ZXID。
4.3. leader服务器与每个follower之间都有一个队列，如果使用同步方式容易引起阻塞。性能上要下降很多。leader将消息发送到该队列
4.4. follower机器从队列中取出消息处理完(写入本地事物日志中)毕后，向leader服务器发送ACK确认。
4.5. leader服务器收到半数以上的follower的ACK后，即认为可以发送commit
4.6. leader向所有的follower服务器发送commit消息。
五：崩溃恢复
1.zookeeper集群中为保证任何所有进程能够有序的顺序执行，只能是leader服务器接受写请求，即使是follower服务器接受到客户端的请求，也会转发到leader服务器进行处理。 2.如果leader服务器发生崩溃，则zab协议要求zookeeper集群进行崩溃恢复和leader服务器选举。 3.ZAB协议崩溃恢复要求满足如下2个要求： 3.1. 确保已经被leader提交的proposal必须最终被所有的follower服务器提交。 3.2. 确保丢弃已经被leader出的但是没有被提交的proposal。 4.根据上述要求，新选举出来的leader不能包含未提交的proposal，即新选举的leader必须都是已经提交了的proposal的follower服务器节点。同时，新选举的leader节点中含有最高的ZXID。这样做的好处就是可以避免了leader服务器检查proposal的提交和丢弃工作。 5.leader服务器发生崩溃时分为如下场景： 5.1. leader在提出proposal时未提交之前崩溃，则经过崩溃恢复之后，新选举的leader一定不能是刚才的leader。因为这个leader存在未提交的proposal。 5.2 leader在发送commit消息之后，崩溃。即消息已经发送到队列中。经过崩溃恢复之后，参与选举的follower服务器(刚才崩溃的leader有可能已经恢复运行，也属于follower节点范畴)中有的节点已经是消费了队列中所有的commit消息。即该follower节点将会被选举为最新的leader。剩下动作就是数据同步过程。