• zookeeper集群中需要通过FastLeader选举算法。Paxos算法 来选取头结点。由于这个特性，某个结点故障时，要耗费时间重新进行header选取，故zk在分布式CAP理论中保证的是CP(一致性和分区容错性)。而spring cloud的eureka集群保证的是AP(高可用和分区容错性)

• 一致（所有节点数据一致），有头（一个leader，所有客户端连接操作通过leader完成），数据数（树结构）

应用场景：

1. 配置一致。集群的配置文件统一管理。在zookeeper上记录配置信息，zookeeper上的记录更改的时候，会通知所有在其上面注册过的系统（观察者模式—observer）.达到统一管理的目的；

2. HA（High Availability）高可用集群启动时，master节点在zookeeper上注册（分为持久化节点，临时性节点–在连接断开后消失，此场景用临时性节点）–active，有另外一台服务器监听该master节点的状态—standBy，一旦发现其消失（由于建立的是临时性节点，一开始的master断开后，该节点会消失），立刻补位，把自己注册到zookeeper上变为master提供服务，挂掉的节点再次启动时，发现已经存在master，自己变为预备服务器—standBy，监控状态master的状态。客户端请求时先在zookeeper中找active的节点，然后再请求该节点。该业务即为主备动态切换；

3. pub/sub发布者，订阅者。发通知，观察者模式。

4. nameserver: rocketMQ在3.2版本之前使用zookeeper来实现服务发现

5. load balance负载均衡。

6. 分布式锁

zookeeper 底层API中的关键点

• zookeeper watch事件是一次性的。watcher是持续性的。 watch的特性：一次性、客户端串行执行、轻量。

• 一次性：对于ZK的watcher，zookeeper有watch事件，是一次性触发的，发生改变时，通知监听的客户端，监听事件消失，需要每次重新设置监听。

• 客户端串行执行：watch的回调是顺序执行的。需要做回调。

• 轻量：watchedEvent是整个watch通知机制的最小单元，只包含通知状态，事件类型和节点路径三部分。不会有具体的内容，比如nodeDataChanged事件，zookeeper只会通知客户端指定节点的数据发生了改变，需要客户端自己去获取具体的内容。

• zookeeper安装过程中遇到的小坑：

  外网访问不通：1.防火墙。2./etc/hosts下的localhost删除。