高可用的高性能的分布式系统协调服务。局部不可用是分布式系统的固有特征,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选举
原子广播
补充:
每个节点在zookeeper中用znode表示。znodes 包含数据变更和acl变更的版本号。znode同样包含时间戳。版本号和时间戳用来帮助zookeeper验证缓存或者协调更新。每次znode数据发生变化都会使版本号增加。例如,每次client接受数据时都会接收到数据的版本号。当client更新或者删除数据时必须给znode提供数据的版本号。如果提供的版本号与实际的版本号不匹配,更新操作会失败。
Zookeeper不是用来做数据库或者存贮大对象的。相反,它只负责协调数据。数据可以来自配置表单、结构化信息等等。这些数据的有一个共同的特点那就是都很小:以Kb为测量单位。Zookeeper的client和server的实现类都会验证znode存储的数据是否小于1M,但是数据应该比平均值小的多。操作大数据将会触发一些消耗时间的额外操作并且影响潜在的操作,因为需要额外的时间在网络和存储介质上转移数据。如果有大数据需要存储,通常的办法是把这些数据存储在专门的大型文件系统上,例如NFS或者HDFS,然后把存储介质的位置存在zookeeper上。
Sequence Nodes -- Unique Naming
当创建一个znode时候,你也可以要求zookeeper在path的结尾单调递增。计数器对每一个znode来说都是唯一的。计数器使用%010d格式化--例如<path>0000000001。注意:计数器使用一个singed int(4bytes)来存储下一个序列值。所以计数器达到2147483647 后会溢出。