标签：成功 correct 自身 改变 rip his ann different mini
ZooKeeper是一个为分布式应用提供分布式协调功能的开源（github）服务。
其主要应用在数据公布与订阅（配置中心），命名服务、分布式锁、集群管理与Master选举、分布式通知等。
在ZooKeeper官网是这样介绍ZooKeeper的：
ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services. All of these kinds of services are used in some form or another by distributed applications. Each time they are implemented there is a lot of work that goes into fixing the bugs and race conditions that are inevitable. Because of the difficulty of implementing these kinds of services, applications initially usually skimp on them ,which make them brittle in the presence of change and difficult to manage. Even when done correctly, different implementations of these services lead to management complexity when the applications are deployed.
上述描写叙述说明像配置管理、命名等这些服务一般被分布式应用程序以某种形式使用，而在使用这些服务时，都会花费大量时间在修复bug和处理竞争条件上。同一时候也可能发送下述情况：
1. 当有变化发送时，难以调整，管理。
2. 这些服务的实现方式不同导致难以部署。
而ZooKeeper就是为了解决上述问题存在的。它提供了一个统一、简洁的分布式协调服务，同一时候差点儿可在不论什么平台使用，可參考ZooKeeper管理员指南——部署与管理ZooKeeper。
就像它所提供服务的对象是分布式应用。它自身也是分布式的。ZooKeeper通常会搭建成集群模式来提供服务，其节点个数一般为奇数个。这是因为其有一个重要特性，即：集群中仅仅有有过半机器是正常工作的，对外即是可用的（过半存活就可以用）。
ZooKeeper数据模型的结构与文件系统十分类似，因此能够看成是一棵树。以下为其结构图
当中每一个节点可称为ZNode，每一个节点都通过其路径唯一标识，如上图所看到的。每一个节点都能够存储数据，它被设计用来存储协同数据。如:状态信息。配置，本地信息等。所以存储的数据不多。
ZNode能够分为两类：永久节点和暂时性节点（Ephemeral node）。
- 永久节点：须要显式创建和删除，在会话（session。在以下介绍）结束后仍然存在。
- 暂时节点：须要显式创建，在删除时，它能够被显式删除。但在使用时，我们一般使用它的特性：在session结束后自己主动删除。如在集群中可通过这特性推断机器是否宕机断开连接（无法维持session）。
同一时候另一个sequential的特性，通过设置此特性，在ZNode的名字后会自己主动加入自增数字sequenceNo。
每一个ZNode都由3部分组成：
1. 状态stat
2. 数据data
3. 孩子节点children
节点状态，对节点的每次改变都会使状态改变，可由状态得知创建顺序等信息。
以下为灾zookeeper.jute中Stat结构
// information shared with the client
class Stat {
long czxid; // created zxid
long mzxid; // last modified zxid
long ctime; // created
long mtime; // last modified
int version; // version
int cversion; // child version
int aversion; // acl version
long ephemeralOwner; // owner id if ephemeral, 0 otw
int dataLength; //length of the data in the node
int numChildren; //number of children of this node
long pzxid; // last modified children
}可參考
znode的stat数据结构
http://coolxing.iteye.com/blog/1871328
client与zk集群通话时须要创建一个session，而每一个session都有一个超时时间t（
The current implementation requires that the timeout be a minimum of 2 times the tickTime (as set in the server configuration) and a maximum of 20 times the tickTime.
）。若zk在t内看不到与此session相关的信息，那么zk定义此session失效，而对于暂时节点这也意味着节点的删除，若设置了监控，那么设置监控的client就可以接受到消息。
zk可对每一个节点设置监控，监视事件有：
- ZOO_CHANGED_EVENT 当前节点改变时触发,zoo_exists()和zoo_get()设置。
- ZOO_CHILD_EVENT 当前节点的子节点改变时触发。zoo_get_children() 和 zoo_get_children2()设置。
- ZOO_CREATED_EVENT 当前节点创建时触发，zoo_exists()设置。
- ZOO_DELETED_EVENT 当前节点删除时触发,zoo_exists()和zoo_get()。zoo_get_children() 和 zoo_get_children2()设置。
- ZOO_NOTWATCHING_EVENT 取消监控时触发
- ZOO_SESSION_EVENT 会话丢失触发
当监控事件发生便会调用监控回调函数，监控回调有2种：
一为全局监控回调，在调用zookeeper_init时设置。当调用上述函数并设置启用监控，当事件发生时便会调用此函数。
二为局部监控回调。仅仅与当前节点有关。
通过形如zoo_wget()设置（加入w）。
监控回调函数模式例如以下：
typedef void (*watcher_fn)(zhandle_t *zh, int type, int state, const char *path,void *watcherCtx);要实现持续watch，可通过在回调函数中又一次设置watch来实现。但在获得事件与再次设置watcher之间的那段时间，节点改变不可知。
Because watches are one time triggers and there is latency between getting the event and sending a new request to get a watch you cannot reliably see every change that happens to a node in ZooKeeper. Be prepared to handle the case where the znode changes multiple times between getting the event and setting the watch again. (You may not care, but at least realize it may happen.)
2. 其他clientwatch那个ZNode。
3. 当ZNode删除。其他client在创建。 但此方法会有羊群效应。
标签：成功 correct 自身 改变 rip his ann different mini
原文地址：http://www.cnblogs.com/tlnshuju/p/7395521.html
