标签：article init state 调整 between nim 简单介绍 parent set
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);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.)
标签：article init state 调整 between nim 简单介绍 parent set
原文地址：http://blog.csdn.net/qq_17713935/article/details/67645278
