Zookeeper应用场景

配置中心

  传统配置管理方式是将配置放在各应用本地，应用启动时读取加载自己的配置文件。当应用数量增大、配置变更频繁、配置量增大时管理维护成本很高且易出错。配置中心就是一个集中管理管理和维护大量配置的专有服务，管理员只在这个特定的服务上维护这些配置信息，所有应用都到配置中心读取，发生变动时配置中心主动触发应用重新加载配置以满足实时修改的要求。
  zookeeper服务就可以当作配置中心来用
  - 首先将配置信息存放到zookeeper的**持久化znode**中。
  - 同时在这些znode上注册数据变更的watch监听。
  - 各应用中集成zookeeper客户端，这些应用客户端订阅各自znode上的watch。
  - 一旦节点数据发生变动，所有订阅该节点的客户端都会收到数据变动通知，以此来触发客户端主动拉取新数据。

负载均衡

  传统的负载均衡方式，例如Nginx，负载集群节点发生变动时，Nginx是不能**实时感知**并动态调整其转发策略的。
  借助zookeeper可以实现这样的动态感知
  - 首先在zookeeper上建立一个所有负载服务器的父节点serverArr，并给它添加watch监听。
  - 负载均衡服务器内集成zookeeper客户端，订阅这个监听。
  - 所有负载以子节点的形式建立在serverArr之下。
  - 当serverArr节点下的子节点发生增减时，都会触发负载均衡服务器内的客户端来重新加载子节点列表，进而重新规划路由方式。

名称服务

  名称服务一个显著特点就是要保证名称的全局唯一性，zookeeper是借助创建有序子节点的方式来实现的。

集群管理

  - 集群控制：对集群节点进行上下线等操作与控制。
  - 集群监控：对集群节点的运行状态进行实时收集。
  - 传统集群管理方式中最常见的是在节点上部署伴生Agent，通常这些Agent都由应用的开发者生成和维护，这些Agent实时向一个控制中心上报所在节点的运行情况，同时也接收中心发来的操作指令以完成对集群的控制。
  - 这种代理思路耦合性低，本身是没有问题的，后续方式也是这样来做的。但是随着集群规模扩张，服务类型增多，技术选型也会变得更多样，这些Agent可能会用不同的语言和技术来实现，此时Agent本身的维护升级就变得复杂起来。
  - 面对这种大规模升级困难和多语言复杂性问题，对Agent的技术架构进行规范化是一个好的解决思路。
  - 用zookeeper实现集群管理主要利用了其临时节点和watch机制。