总结zookeeper使用场景

FXMAR

　　zookeeper是一个基于观察者的模式的分布式服务管理框架，负责存储和管理大家都关心的数据，并且接受观察者的注册，一旦发生变化，zookeeper就将通知到这些观察者做相应的变化。
核心场景：解决分布式系统中的一致性问题
核心特性: zookeeper会维护一个目录结点树，每个节点znode可以被监控，包括监控某个目录中存储的数据变化，子目录节点的变化，一旦变化可以通知设置监控的客户端。
术语：客户端有二种，一种是client连接zookeeper的客户端，另一种是follower做为客户端与leader连接。任何一台leader或者follower都可以做为客户端连接zookeeper服务器，主要操作如下：
1.创建与zookeeper的连接，通过该对象来在zookeeper上维护目录树，ZooKeeper zk = new ZooKeeper...
2.在zookeeper上创建一个给定路径的znode....
3.基于znode做相应的数据存储，子节点增减等操作
基于核心特性的主要用途：
1.单server单进程内的锁好实现，但是更复杂的跨越多个server多进程的分布式锁zookeeper可以轻松实现。
2.统一配置，集群中的每个server配置都需要改动，而通过zookeeper核心特性，只需要其中的一个配置，就会通过watch通知到其它的server自动更新。
3.类似于jndi,给使用者返回一个标志资源的名称，只不过zookeeper利用了目录的层次结构唯一标志资源（资源应该是znode或者对应的server）
4.zookeeper用来管理集群（感觉应该是zookeeper将管理的重任代理给了leader，zookeeper会通过指定的端口与leader交换信息，zookeeper还会指定另一个端口用来election与服务器通信）
leader-follower有点类似master-save的模式. zookeeper可以用来管理由leader与follower组成的集群。leader election 动态选择master,避免了传统意义上的单master容易出现的单点故障，选择的策略就是找当前序列号最小的follower做为leader。
这样确保集群的情况下，总是存在一个leader。
leader的目的就是管理服务器的状态，是否可用。
一旦follower挂了，follower与leader之间的长连接就会在指定的时间之后断开，zookeeper就会将对应的znode删除，并通知其它的follower.
一旦leader挂了，那么zookeeper就会从剩下的followers对应的znode中选择序列号最小的充当leader。
leader election主要利用了SEQUENTIAL类型的znode。该node会有序列号，election总是选最小序列号的znode对应的server做为leader。
5.同步队列：有点类似于barrier，当队列中的所有成员都加入才触发。
6.先进先出队列，比如PERSISTENT_SEQUENTIAL,仍然利用了通过SEQUENTIAL生成的序列号。

整理内容来自：http://wenku.baidu.com/view/9f9dc1d749649b6648d7471a.html