zookeeper
ZooKeeper是什么？
高可用的高性能的分布式系统协调服务。局部不可用是分布式系统的固有特征，ZooKeeper可以很好的地处理这种情况。
下面从三个方面来理解ZooKeeper服务：数据模型、操作、实现
数据模型
可以把zookper看成一个文件系统，文件系统中的所有文件形成一个数状结构，zookeeper维护着这样的树形层次结构，树中的节点称为znode。每个znode有一个与之相关联的ACL（Access Control List）。这种数据模型示意图如下：
znode通过路径被引用，而且要采用绝对路径，即必须以/开头。znode存储的数据要<1m。
znode类型
短暂znode：回话结束，zookeeper就会把短暂znode删除，短暂znode不可以有子节点。
持久znode：回话结束也不会被删除，除非客户端明确要删除此znode，持久znode可以有子节点。
对于在特定时刻需要知道有哪些分布式资源可用的应用来说，使用短暂znode比较合适。
znode的观察机制
znode以某种方式发生变化时，“观察”（watch）机制可以让客户端得到通知。可以针对ZooKeeper服务的“操作”来设置观察，该服务的其他操作可以触发观察。比如，客户端可以对某个客户端调用exists操作，同时在它上面设置一个观察，如果此时这个znode不存在，则exists返回false，如果一段时间之后，这个znode被其他客户端创建，则这个观察会被触发，之前的那个客户端就会得到通知。
操作
ZooKeeper有9种基本操作：
| 操作 |
描述 |
| create |
创建一个znode（必须有父节点） |
| delete |
删除一个znode（该znode不能有任何子节点） |
| exists |
测试一个znode是否存在，并且查询它的元数据 |
| getACL,setACL |
获取/设置一个znode的ACL |
| getChildren |
获取一个znode的子节点列表 |
| getData,setData |
获取/设置一个znode所保存的数据 |
| sync |
将客户端的znode视图与ZooKeeper同步 |
Zookeeper中的更新操作是有条件的。在使用delete或者setData操作时必须提供被更新znode的版本号，如果版本号不匹配，则更新操作失败。
API
目前主要有java和C两种客户端，每种操作都有同步和异步两种执行方式。
观察触发器
可以设置观察的操作：exists,getChildren,getData
可以触发观察的操作：create,delete,setData
| 观察触发器 |
|||||
| 设置观察的操作 |
create |
delete |
setData |
||
| znode |
子节点 |
znode |
子节点 |
||
| exists |
NodeCreated |
NodeDeleted |
NodeDataChanged |
||
| getData |
NodeDeleted |
NodeDataChanged |
|||
| getChildren |
NodeChildrenChanged |
NodeDeleted |
NodeChildrenChanged |
||
NodeCreated:节点创建事件
NodeDeleted：节点被删除事件
NodeDataChanged：节点数据改变事件
NodeChildrenChanged：节点的子节点改变事件
ACL
每个znode被创建时都会带有一个ACL列表，用于决定谁可以对它执行何种操作。
| ACL权限 |
允许的操作 |
| CREATE |
create（子节点） |
| READ |
getChildren getData |
| WRITE |
setData |
| DELETE |
delete（子节点） |
| ADMIN |
setACL |
每个ACL都是身份验证模式、符合该模式的一个身份和一组权限的组合。身份验证模式有三种：
digest:用户名，密码
host:通过客户端的主机名来识别客户端
ip： 通过客户端的ip来识别客户端
所以我们可以类似这样构建一个ACL类：
new ACL(Perms.READ,new Id("host","example.com"));
这个ACL对应的身份验证模式是host
符合该模式的身份是example.com
权限的组合是：READ
实现
Zookeeper有两种运行模式：
独立模式（standalone mode):只运行在一台服务器上，适合测试环境
复制模式（replicated mode)：运行于一个集群上，适合生产环境，这个计算机集群被称为一个“集合体”（ensemble）。Zookeeper通过复制来实现高可用性，只要集合体中半数以上的机器处于可用状态，它就能够保证服务继续。为什么一定要超过半数呢？这跟Zookeeper的复制策略有关：zookeeper确保对znode树的每一个修改都会被复制到集合体中超过半数的机器上。
生产环境，zookeeper集群的服务器数目应该是奇数。
Zookeeper集群中的角色及其职责
领导者
1.管理写请求
跟随者
1.响应客户端的读请求
2.负责把客户端提交的写请求转发给领导者
回话
客户端与zookeeper集群中的某个服务器建立连接，就建立了一个回话，回话可以过期，可以设置ping周期来防止回话过期。
滴答（tick time）：定义了zookeeper中的基本时间周期，其他设置都是根据滴答参数来定义的。2个滴答=<回话时间<=20个滴答时间
状态
CONNECTING,CONNECTED,CLOSED
Zookeeper采用的算法：Zab（待续）
leader选举
原子广播