【分布式协调服务】-- zookeeper 出现背景

集群服务的问题：

1. 协议地址的维护
   一个服务分别部署在多个服务器上，每个服务器的地址都是一个协议地址
2. 负载均衡机制
   转发请求，均衡各个服务节点的负载
3. 服务动态上下线感知
   （上线：某个服务发布上线调用者可以知晓； 下线：如若集群中某个节点服务出问题宕机可以迅速定位）

如何解决集群服务问题

思路: (我们需要一个什么样的东西来解决上述问题)

1. 需要有一个中间件
2. 发布服务的时候可以注册到中间件上去，在中间件上维护一个类似电话簿的功能（存着所有目标服务器的地址），断开时也可以立即知晓。
3. 客户端只需要拿到中间件地址即可知道目标服务器的所有信息
4. 中间件可以感知各个服务的上下线状况，
5. 这样开发者更专注与其应用本身的逻辑而不是关注分布式系统处理。

引入了zookeeper(分布式协调服务)

zookeeper是用来协调各个服务访问的顺序性，也用来管理中间件。

1. zookeeper起源于雅虎，最初设计目标是解决共享资源竞争的问题，解决了多节点访问共享资源时候各个节点的接入顺序，（各个节点都是独立的进程）
2. 后来，为了防止单点故障，zookeeper作为了一个中间件也需要做集群，来保证本身的高可用。
3. 由此引入了zookeeper集群中各个中间件之间的数据同步问题，集群中的每个节点都可以接收到请求，而且每个节点的数据都必须要保持一致，这样就引入了一个leader节点来负责协调和做数据同步操作。因为集群中