应用场景
1、分布式协调
分布式协调简单说就是有人对ZooKeeper中的数据做了监听，如果修改了ZooKeeper中被监听的数据，ZooKeeper反过来会告诉给发起监听的人数据的变更
2、元数据管理
3、高可用
支持主从选举
4、分布式锁
支持分布式锁，高并发场景有性能问题
ZooKeeper集群架构
leader领导者
为客户端提供读和写功能，负责投票的发起与决议，集群里面只有leader才有写的功能
follower跟随者
为客户端提供读服务，如果是写的请求则转发到leader,在选举过程进行投票
observer观察者
为客户端提供读服务，如果是写的请求则转发到leader。
不参与leader的选举投票，也不参与写的过半原则机制。在不影响写的前提下，提高集群读的性能，此角色于zookeeper3.3系列新增的角色。
client
连接zookeeper集群的使用者，请求的发起者，独立于zookeeper集群的角色
zookeeper读写机制
在zk选举中，如果有过半的节点都选一个节点为leader的话，那么这个节点就会是leader节点
，所以zk集群一般都是奇数台，节省机器。
读
客户端可以去任意节点读数据
写
所有的客户端只能往leader节点上面写数据，如果客户端连接的是follower节点，则follower会吧写请求转发给leader节点。
leader接受到写请求就会往其他节点同步，如果有超过一半的节点收到消息后发来ack,那么leader节点就对这条消息进行commit
,如果集群越大，接收ack的时间就越长，也就是节点越多会增加集群的读性能，也会影响集群的写性能。
为了解决这个问题，zk中增加一个observer节点，不参与投票，只负责同步数据，所以引入这个角色目的就是为了增加集群读的性能，然后不影响集群的写性能
第一阶段：每次的数据写入事件作为提案广播给所有Follower结点；可以写入的结点返回确认信息ACK；
第二阶段：Leader收到一半以上的ACK信息后确认写入可以生效，向所有结点广播COMMIT将提案生效。
zk特点
1、一致性
客户端无论连接那个节点，读取的数据都是一样的
根据写入过程的两阶段的描述，我们知道ZooKeeper保证的是最终一致性，
即Leader向客户端返回写入成功后，可能有部分Follower还没有写入最新的数据，所以是最终一致性
2、实时性
zk保证客户端在一定时间内获取到结果，但是不保证两台客户端同时获取到刚刚更新的消息
3、原子性
leader在同步数据的时候，同步过程保证事务性，要么都成功，要么都失败
4、原子性
一台服务器上如果消息a在消息b前发布，那么所有的server上的消息a都是在消息b前发布的。
zk如何保证数据一致性
ZooKeeper保证数据一致性用的是ZAB协议。通过这个协议来进行ZooKeeper集群间的数据同步，保证数据的一致性
两阶段提交+过半写机制
leader节点会把数据通过proposal请求发到所有节点，节点收到数据后会存储到磁盘上面，然后发送一个ack给leader
,如果leader接收到过半节点发送到ack响应，就会发送commit消息给各个节点，各个节点就会把消息放到内存里面（保证性能）
，这样这个消息用户就可以看到了。
zk选举过程
zk每个节点都会包含以下两个数据
zxid：数据ID，每次数据变动都会自增，初始都是0（编号越大在选择算法中的权重越大。）
sid: 该投票信息所属的serverId （越大说明数据越新，在选举算法中数据越新权重越大。）
规则
1、第一次投票都是给自己投票
2、服务器收到投票后，会先比较ZXID，ZXID大的当leader,如果一样，则比较SID,如果SID大的，当leader
3、每次投票以后，服务器都会统计所有的投票，只要过半的机器投了相同的机器，那么Leader就选举成功了
例子
假设有两台机器sid=1 ,sid=2,进行投票 （sid,zxid）
第一次投票：
第一台机器投票给自己（1，0），
第二台机器也投票给自己（2，0），
第二次投票：
第一台机器收到的收到的是 （2，0），首先zxid一样，但是sid比自己大，所以投票改成（2，0）
第二台机器收到的是（ 1，0），首先zxid一样，但是sid没有自己大，所以投票改成自己（2，0）
因为已经超过半数，所以机器2当选。
如果集群在运行的过程中Follower节点宕机了，对Leader节点是不影响的，
如果集群在运行的过程中Leader节点宕机了，就会进行重新选举，重新选举的流程跟上述一致
ZooKeeper是如何保证事务顺序的呢？
zxid:
ZXID由Leader节点生成，有新写入事件时，Leader生成新ZXID并随提案一起广播，
每个结点本地都保存了当前最近一次事务的ZXID，ZXID是递增的，所以谁的ZXID越大，就表示谁的数据是最新的
Leader为了保证提案按ZXID顺序生效，使用了一个ConcurrentHashMap，记录所有未提交的提案，命名为outstandingProposals，
key为ZXID，Value为提案的信息。对outstandingProposals的访问逻辑如下
1、每发起一个提案，会将提案的ZXID和内容放到outstandingProposals中，作为待提交的提案；
2、收到Follower的ACK信息后，根据ACK中的ZXID从outstandingProposals中找到对应的提案，对ACK计数；
3、执行tryToCommit尝试将提案提交，判断流程如下：
3.1：判断当前ZXID之前是否还有未提交提案，如果有，当前提案暂时不能提交；
3.2：判断提案是否收到半数以上ACK，如果达到半数则可以提交；
3.3：如果可以提交，将当前ZXID从outstandingProposals中清除并向Followers广播提交当前提案；
Leader是如何判断当前ZXID之前是否还有未提交提案的呢？由于前提是保证顺序提交的，
所以Leader只需判断outstandingProposals里，当前ZXID的前一个ZXID是否存在
Zab协议
Zab协议 的全称是 Zookeeper Atomic Broadcast （Zookeeper原子广播）
Zab协议是为分布式协调服务Zookeeper专门设计的一种 支持崩溃恢复 的 原子广播协议
，是Zookeeper保证数据一致性的核心算法。Zab借鉴了Paxos算法，但又不像Paxos那样，
是一种通用的分布式一致性算法。它是特别为Zookeeper设计的支持崩溃恢复的原子广播协议
zookeeper与Eureka 对比
zk保证CP
注册中心一般对可用性对要求高于一致性，因为ZK选举过程中 zk集群是不可用的。
Eureka保证AP
在设计的时候优先保证可用性，几个节点挂掉不会影响正常节点的工作，其余节点一眼可以提供注册和查询服务
同时eureka还有自我保护功能，在15分钟内 85%的节点都没正常心跳，此时不会从注册中心摘掉因为长时间没有心跳而过期的服务