Zookeeper详解（六）：Zookeeper的应用场景

标签：核心   应用程序   好用   AC   功能   形式   方式   分布式   分布式框架   

数据发布和订阅

也就是常用的配置管理，将数据信息发布到一个或者多个ZK节点上，应用程序监听这些节点当有数据变化时就获取这些变化并应用到程序中，实现动态更新配置的功能。发布订阅中通常有推拉两种模式，ZK采用推拉结合，客户端注册感兴趣的节点，一旦节点发生变化服务器会发出Watcher事件通知（推），然后客户端收到消息后主动去服务器提取变化（拉）。

这种配置管理通常应用在具有配置通用性的场景中，比如机器列表、某些参数的开关或者数据库配置信息等。

• 这些信息通常体量小

• 在应用运行时会随时调整

• 这些应用（至少是某一组应用）都使用相同的配置

常规解决办法是本地配置文件或者内存变量（通过JMX方式对正在运行的JAVA程序进行修改）。这些常规办法在集群规模较小的时候比较方便但是集群规模一大管理就比较困难。

比如数据库配置信息变化

• 首先在ZK上创建一个节点叫做 /Configuration 这里面有一个APP名称节点表示特定APP，这个APP名称节点下面有一个叫做 dbConfig的节点用于存储数据库配置信息（/Configuration-->APP1-->dbConfig）

• 然后将配置信息写入到这个节点（这些信息肯定是序列化后写入的，如果在程序中不是以对象形式存在也可以不用序列化）

• 应用程序启动后读取这个节点数据，然后在这个节点上注册一个Watcher事件，当数据有变化时再次读取该节点数据并应用到自己的程序上。

负载均衡

ZK提供的负载属于软负载均衡服务。通常的做法就是动态的DNS服务，如果你的机器数量比较少你可以手动在内网DNS上配置这些域名，你要知道一个域名就对应一个IP。如果集群规模比较大手动维护这些信息相当繁琐；另外你还可以采用HOST的方式就是在服务器上配置本地HOST把这些域名写进去，还是一样的问题规模小传统方式都很好用，但是规模大尤其是有时候需要动态扩容或者缩容的时候你再去手动维护这些HOST或者DNS记录显然就不能满足业务需求。

在Zookeeper中如何解决呢？下面的名称就是名字不一定你也这样取，毕竟节点名称是自定义的。

• 首先建立一个节点叫做 /DDNS 这下面包含所有应用的名字比如APP1，APP2等，每个应用名字节点下面又一个域名比如  app1.servers.abc.com这样一个域名（/DDNS-->APP1-->app1.servers.abc.com）后面这个域名就是改APP1集群使用的，这个节点包含的数据可以是IP:PORT或者多个IP:PORT，看下图

• 的
  

Zookeeper详解（六）：Zookeeper的应用场景

标签：核心   应用程序   好用   AC   功能   形式   方式   分布式   分布式框架   

原文地址：http://blog.51cto.com/littledevil/2132007