zookeeper学习三：zookeeper应用场景
一：配置中心
在平常的业务开发过程中，我们通常需要将系统的一些通用的全局配置，例如机器列表配置，运行时开 关配置，数据库配置信息等统一集中存储，让集群所有机器共享配置信息，系统在启动会首先从配置中 心读取配置信息，进行初始化。传统的实现方式将配置存储在本地文件和内存中，一旦机器规模更大， 配置变更频繁情况下，本地文件和内存方式的配置维护成本较高，使用zookeeper作为分布式的配置中 心就可以解决这个问题。
我们将配置信息存在zk中的一个节点中，同时给该节点注册一个数据节点变更的watcher监听，一旦节 点数据发生变更，所有的订阅该节点的客户端都可以获取数据变更通知。
二：负载均衡
建立server节点，并建立监听器监视servers子节点的状态（用于在服务器增添时及时同步当前集群中服 务器列表）。在每个服务器启动时，在servers节点下建立具体服务器地址的子节点,并在对应的字节点 下存入服务器的相关信息。这样，我们在zookeeper服务器上可以获取当前集群中的服务器列表及相关 信息，可以自定义一个负载均衡算法，在每个请求过来时从zookeeper服务器中获取当前集群服务器列 表，根据算法选出其中一个服务器来处理请求。
三：命名服务
命名服务是分布式系统中的基本功能之一。被命名的实体通常可以是集群中的机器、提供的服务地址或 者远程对象，这些都可以称作为名字。常见的就是一些分布式服务框架（RPC、RMI）中的服务地址列 表，通过使用名称服务客户端可以获取资源的实体、服务地址和提供者信息。命名服务就是通过一个资 源引用的方式来实现对资源的定位和使用。在分布式环境中，上层应用仅仅需要一个全局唯一名称，就 像数据库中的主键。
在单库单表系统中可以通过自增ID来标识每一条记录，但是随着规模变大分库分表很常见，那么自增ID 有仅能针对单一表生成ID，所以在这种情况下无法依靠这个来标识唯一ID。UUID就是一种全局唯一标 识符。但是长度过长不易识别。
- 在Zookeeper中通过创建顺序节点就可以实现，所有客户端都会根据自己的任务类型来创建一个顺 序节点，例如 job-00000001
- 节点创建完毕后，create()接口会返回一个完整的节点名，例如：job-0000002
- 拼接type类型和完整节点名作为全局唯一的ID
四：DNS服务
- 域名配置
- 域名解析
应用解析时，首先从zk域名节点中获取域名映射的IP和端口。
- 域名变更
每个应用都会在在对应的域名节点注册一个数据变更的watcher监听，一旦监听的域名节点数据变更， zk会向所有订阅的客户端发送域名变更通知。
五：集权管理
集群管理主要体现在
- 集权控制：对集群中节点进行操作与控制
- 集权监控：对集群节点运行状态的收集
在日常开发和运维过程中，我们经常会有类似以下的需求：
- 希望知道当前集权究竟有多少机器工作
- 对集群中每台机器的运行状态进行数据收集
- 对集群中机器进行上下线操作传统方式
传统方式
在传统的基于Agent的分布式集群管理体系中，都是通过在集群中的每台机器上部署一个Agent,由这个Agent负责主动向指定的一个监控中心系统（监控中心系统负责将所有数据进行集中处理，形成一系列报表，并负责实时报警，以下简称“监控中心”）汇报自己所在机器的状态，在集群规模适中的场景下，这确实是一种在生产实践中广泛应用的解决方案，能够快速有效的实现分布式环境集群监控，但是一旦系统的业务场景增多，集群规模变大之后，改解决方案的弊端也就显现出来。
大规模升级困难，编程语言多样性
随着分布式系统规模日益扩大，集群中机器的数量越来越多。有效的集群管理越来越重要了， zookeeper集群管理主要利用了watcher机制和创建临时节点来实现。以机器上下线和机器监控为例
新增机器的时候，将Agent部署到新增的机器上，当Agent部署启动时，会向zookeeper指定的节 点下创建一个临时子节点，当Agent在zk上创建完这个临时节点后，当关注的节点 zookeeper/machines下的子节点新加入新的节点时或删除都会发送通知，这样就对机器的上下线 进行监控。
在机器运行过程中，Agent会定时将主机的的运行状态信息写入到/machines/hostn主机节点，监 控中心通过订阅这些节点的数据变化来获取主机的运行信息。