三：ZOOKEEPER应用场景

zookeeper是Google chubby的开源实现，它包含了一个简单的原语集，是在Paxos算法的基础上改良，基于ZAB协议实现的，提供了一系列服务，包括配置中心，分布式协调服务，分布式队列，分布式锁，负载均衡，命名服务，集群管理Master选举等一系列场景，下面简单介绍一下：

一：配置中心，zk提供了一系列类似UNIX文件系统的命名空间，开发者可以将配置写入zk的命名空间中，该场景主要用于分布式系统中配置，因为分布式系统中如果更改配置是很麻烦的事情，所以讲一些通用的配置写入zk中，系统在启动的时候会想zk中读取一次数据，同事注册节点的监听，zk采用PUSH+PULL的方式更新数据，需要注意的是向zk节点中写入的数据必须数据量比较小，不适合大数据的操作

二：负载均衡，此处的负载均衡是一种软负载，相对于nginx之类的硬件负载，一般在分布式系统中，都是多个服务启动来保证负载和高可用，服务的消费者需要在其中选择一个进行业务逻辑的处理

比如分布式中间件MQ KafkaMQ就是通过zk来做到生产者消费者的负载均衡

a：生产者负载均衡：

在Broker启动的时候，会向zk中注册一个临时节点，同时还会注册该节点下可以订阅的topic的信息，kafkamq有分区的概念，在生产者发送消息的时候必须选择一个broker进行发送，因此在Kafkamq子啊启动的时候会把所有broker和它对应的分区消息写入zk中，默认策略是轮训策略，生产者在获取到zk的分区列表后，会按照borker进行发送，

b：消费者负载均衡

消费者在启动的时候，会向zk注册信息，是一个临时节点，包含了他要订阅的信息

消费过程中，一个消费者可能消费一个或者多个分区的信息，但是一个分区的信息只能被一个消费者消费，他的消费策略是

每个分区针对同一个group只挂载一个消费者。

如果同一个group的消费者数目大于分区数目，则多出来的消费者将不参与消费。

如果同一个group的消费者数目小于分区数目，则有部分消费者需要额外承担消费任务。

如果有消费者down，其他消费者感知到变化，（watch机制）就会重新出发负载均衡

三：命名服务

在分布式系统中，可以通过命名服务来获取到ip，地址等等信息，就是通过这个服务获取很多信息，例如阿里的Dubbo框架就是通过zk来实现命名服务

服务的提供者在启动的时候回向/dubbo/service_name/providers节点下面写入自己的信息，完成服务的发布

服务的消费者在启动的时候会先订阅/dubbo/service_name/providers提供者的url地址，同事向向/dubbo/service_name/consumers下面写入信息，

写入的都是临时节点，因此可以watcher所有监听

此外dubbo还提供了服务的监听，是通过订阅providers和consumers节点实现

四：分布式协调通知

zk采用PUSH-PULL机制实现了分布式环境下的数据更新，PC订阅zk节点下面的，同事将wathcer传给zk，在数据发送变化的时候，客户端进行回调wathcer进行数据更新，此处watcher存储在zk的客户端

五：集群管理Master选举

集群管理：

zk里面可以通过订阅节点的方式，监听子节点

zk里面还可以通过监听临时节点的方式实现监听

Master选举：

在一些分布式环境下，往往会出现一种场景，需要一台pc去处理，然后集群内部的pc共享结果即可，没有必要把集群内部的PC浪费在多余的操作上，

利用zk的强一致性，可以保证了，同一时间只允许一个客户端注册成功一个节点，那么只需要集群内部pc去争抢master节点，抢到了就是master，然后去执行业务逻辑。

还有一种就是zk的临时有序节点，在启动的时候，会同时向一个父节点下面注册临时有序节点，可以选取序号最高或者最小的最为master，如果down掉了，最小或者最高就会消息，那么会重新进行选举

六：分布式锁与分布式队列

分布式锁：

zk提供独占锁和共享锁两种锁

1：独占锁，一个获取到之后，其余只能等待

2：共享锁，一个获取到之后，其余还能进行读操作，但是写操作要等到锁释放

分布式队列：

jdk里面提供了CyclicBarrier的实现，简单一点就是运行员比赛的时候，要等到所有人准备好才开始。