zookeeper
官方文档上这么解释zookeeper，它是一个分布式服务框架，是Apache Hadoop的一个子项目，它主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。上面的解释有点抽象，简单来说zookeeper=文件系统+监听通知机制。
zk的数据模型
zk的数据模型很像数据结构当中的树，也很像文件系统的目录。
树是由结点所组成，Zookeeper的数据存储也同样是基于结点，这种节点叫做Znode。
但是，不同于树的结点，Znode的引用方式是路径引用，类似于文件路径：
/ 动物 / 仓鼠
/ 植物 / 荷花
这样的层级结构，让每一个Znode节点拥有唯一的路径，就像命名空间一样对不同信息作出清晰的隔离。
znode
data：Znode存储的数据信息。 ACL：记录Znode的访问权限，即哪些人或哪些IP可以访问本节点。
stat：包含Znode的各种元数据，比如事务ID、版本号、时间戳、大小等等。
child：当前节点的子节点引用，类似于二叉树的左孩子右孩子。
这里需要注意一点，Zookeeper是为读多写少的场景所设计。Znode并不是用来存储大规模业务数据，而是用于存储少量的状态和配置信息，每个节点的数据最大不能超过1MB
操纵这些结点，zk提供了简单的API
create 创建节点
delete 删除节点
exists 判断节点是否存在
getData 获得一个节点的数据
setData 设置一个节点的数据
getChildren 获取节点下的所有子节点
这其中，exists，getData，getChildren属于读操作。Zookeeper客户端在请求读操作的时候，可以选择是否设置Watch。
watch
我们可以理解成是注册在特定Znode上的触发器。当这个Znode发生改变，也就是调用了create，delete，setData方法的时候，将会触发Znode上注册的对应事件，请求Watch的客户端会接收到异步通知。
具体交互过程如下：
1.客户端调用getData方法，watch参数是true。服务端接到请求，返回节点数据，并且在对应的哈希表里插入被Watch的Znode路径，以及Watcher列表
2.当被Watch的Znode已删除，服务端会查找哈希表，找到该Znode对应的所有Watcher，异步通知客户端，并且删除哈希表中对应的Key-Value。
zk的一致性
为了防止zk自身所在的服务器挂掉，所以zk本身也是一个分布式系统
Zookeeper的集群
Zookeeper Service集群是一主多从结构。在更新数据时，首先更新到主节点（这里的节点是指服务器，不是Znode），再同步到从节点。在读取数据时，直接读取任意从节点。为了保证主从节点的数据一致性，Zookeeper采用了ZAB协议，这种协议非常类似于一致性算法Paxos和Raft。
ZAB即zookeeper atomic broadcast
在学习ZAB之前，需要首先了解ZAB协议所定义的三种节点状态：
Looking ：选举状态。
Following ：Follower节点（从节点）所处的状态。
Leading ：Leader节点（主节点）所处状态。
还需要知道最大ZXID的概念：
最大ZXID也就是节点本地的最新事务编号，包含epoch和计数两部分。epoch是纪元的意思，相当于Raft算法选主时候的term。这个ZXID也就是：
1.服务器中存放的最新数据version
2.值越大说明数据越新,在选举算法中数据越大权重越大
逻辑时钟：
1.逻辑时钟也叫投票的次数,同一轮投票过程中的逻辑时钟值是相同的;
2.每投完一次票这个数据就会增加,然后与接受到的其他服务器返回的投票信息中的数值相比;
3.根据不同的值做出不同的判断;
zk启动时选择（全新集群选举）
一个zookeeper集群刚刚搭建起来,没有任何数据,他的选举,就叫全新集群选举
假设目前有5台服务器,每台服务器均没有数据,他们的编号分别是1,2,3,4,5, 也就是说ZXID是0
服务器1启动
服务器1启动,给自己投票,然后发投票信息,由于其他机器还没有启动,所以服务器器1收不到反馈信息,服务器1的状态一直属于Looking;所以zk至少需要两台机器才可以进行选举。
服务器2启动
服务器2启动,给自己投票,同时与之前启动的服务器1交换结果,由于服务器2的编号大所以服务器2胜出, 票数为1+1(其中一票来自服务器1的那票)但此时投票数没有大于半数,所以两个服务器的状态依然是Looking;
服务器3启动
1.服务器3启动,给自己投票,同时与之前启动的服务器1,2,交换信息,由于服务器3的编号最大, 所以服务器3胜出(自己的1票+前面两个的2票),此时投票数正好是大于半数,所以服务器3称 为leader服务器1,2称为follower
服务器4启动
服务器4启动,给自己投票,同时与之前启动的服务器1,2,3交换信息,尽管服务器4的编号大, 但之前服务器3已经胜出,所以服务器4只能为follower;
服务器5启动
后面的逻辑同服务器4称为小弟
非全新集群选举
假如Zookeeper当前的主节点挂掉了，集群会进行崩溃恢复。ZAB的崩溃恢复分成三个阶段：
1.Leader election
选举阶段，此时集群中的节点处于Looking状态。它们会各自向其他节点发起投票，投票当中包含自己的服务器ID和最新事务ID（ZXID）。
1.逻辑时钟小的选举结果被忽略,重新投票
2.同一逻辑时钟后（同一次投票次数后）,数据id大的胜出
3.数据id相同的情况下,服务器id大的胜出
4. 如若有一台机器得到半数以上的票则胜出
根据上面的规则选出leader，如果存在这样的节点，该节点将会成为准Leader，状态变为Leading。其他节点的状态变为Following。
2.Discovery
发现阶段，用于在从节点中发现最新的ZXID和事务日志。或许有人会问：既然Leader被选为主节点，已经是集群里数据最新的了，为什么还要从节点中寻找最新事务呢？
这是为了防止某些意外情况，比如因网络原因在上一阶段产生多个Leader的情况。所以这一阶段，Leader集思广益，接收所有Follower发来各自的最新epoch值。Leader从中选出最大的epoch，基于此值加1，生成新的epoch分发给各个Follower。
各个Follower收到全新的epoch后，返回ACK给Leader，带上各自最大的ZXID和历史事务日志。Leader选出最大的ZXID，并更新自身历史日志。
3.Synchronization
同步阶段，把Leader刚才收集得到的最新历史事务日志，同步给集群中所有的Follower。只有当半数Follower同步成功，这个准Leader才能成为正式的Leader。
自此，故障恢复正式完成。
ZAB协议中的Broadcast
ZAB实现写数据
什么是Broadcast呢？简单来说，就是Zookeeper常规情况下更新数据的时候，由Leader广播到所有的Follower。其过程如下：
1.客户端发出写入数据请求给任意Follower。
2.Follower把写入数据请求转发给Leader。
3.Leader采用二阶段提交方式，先发送Propose广播给Follower。
4.Follower接到Propose消息，写入日志成功后，返回ACK消息给Leader。
5.Leader接到半数以上ACK消息，返回成功给客户端，并且广播Commit请求给Follower。
Zab协议既不是强一致性，也不是弱一致性，而是处于两者之间的单调一致性。它依靠事务ID和版本号，保证了数据的更新和读取是有序的。
zk的应用场景
1.分布式锁这是雅虎研究员设计Zookeeper的初衷。利用Zookeeper的临时顺序节点，可以轻松实现分布式锁。
2.服务注册和发现利用Znode和Watcher，可以实现分布式服务的注册和发现。最著名的应用就是阿里的分布式RPC框架Dubbo。
3.共享配置和状态信息Redis的分布式解决方案Codis，就利用了Zookeeper来存放数据路由表和 codis-proxy 节点的元信息。同时 codis-config 发起的命令都会通过 ZooKeeper 同步到各个存活的 codis-proxy。
此外，Kafka、HBase、Hadoop，也都依靠Zookeeper同步节点信息，实现高可用。
