Zookeeper典型应用场景

1）数据发布/订阅
数据的发布与订阅，顾名思义就是一方把数据发布出来，另一方通过某种手段获取。
通常数据发布与订阅有两种模式：推模式和拉模式，推模式一般是服务器主动往客户端推送信息，
拉模式是客户端主动去服务端请求目标数据（通常采用定时轮询的方式）
Zookeeper采用两种方式互相结合：发布者将数据发布到Zookeeper集群节点上，
订阅者通过一定的方法告诉Zookeeper服务器，自己对哪个节点的数据感兴趣，那么在服务端数据发生变化时
，就会通知客户端去获取这些信息。
（2）负载均衡
　首先在服务端启动的时候，把自己在zookeeper服务器上注册成一个临时节点。
zookeeper拥有两种形式的节点，一种是临时节点，一种是永久节点。这两种节点后面的会有较为详细的介绍
。注册成临时节点后，再服务端出问题时，节点会自动的从zookeeper上删除，
如此zookeeper服务器上的列表就是最新的可用的列表。
　客户端在需要访问服务器的时候首先会去Zookeeper获得所有可用的服务端的连接信息。
　客户端通过一定的策略（如随机）选择一个与之建立连接。
　当客户端发现连接不可用时，会再次从zookeeper上获取可用的服务端连接，
并同时删除之前获取的连接列表。
　 （3）命名服务
　提供名称的服务。如一般使用较多的有两种id，一种是数据库自增长id，一种是UUID，两种id都有局限，
自增长id仅适合在单表单库中使用，uuid适合在分布式系统中使用但由于id没有规律难以理解。
而ZK提供了一定的接口可以用来获取一个顺序增长的，可以在集群环境下使用的id。
　 （4）分布式协调，通知，心跳服务
　在分布式服务系统中，我们常常需要知道哪个服务是可用的，哪个服务是不可用的，
传统的方式是通过ping主机来实现的，ping得200的结果说明说明该服务是OK的。
　而在使用
zookeeper时，可以将所有的服务都注册成一个临时节点，我们判断一个服务是否可用，
只需要判断这个节点是否在zookeeper集群中存在就可以了，不需要直接去连接和ping服务所在主机，
减少系统的复杂度和对服务主机的压力。