zookeeper原理浅析（二）

参考&＃xff1a;https://www.cnblogs.com/leocook/p/zk_1.html

代码&＃xff1a;https://github.com/littlecarzz/zookeeper

1. 数据模型

1.1. 只适合存储小数据

Zk维护着一个逻辑上的树形层次结构&＃xff0c;树中的节点称为znode&＃xff0c;个znode都有一个ACL&＃xff08;权限控制&＃xff09;。Zookeeper是被设计用来协调服务的&＃xff0c;因此znode里存储的都是小数据&＃xff0c;而不是大容量的数据&＃xff0c;数据容量一般在1MB范围内。

1.2. 操作的原子性

Znode的数据读写是原子的&＃xff0c;要么读或写了完整的数据&＃xff0c;要么就失败&＃xff0c;不会出现只读或写了部分数据。

1.3. Znode的路径

和Unix中的文件系统路径格式很想&＃xff0c;但是只支持绝对路径&＃xff0c;不支持相对路径&＃xff0c;也不支持点号&＃xff08;”.”和”..”&＃xff09;。

1.4. 短暂的znode和持久的znode

Znode有两种类型&＃xff1a;短暂的和持久的。短暂的znode生命周期仅限创建它的客户端与服务器端之间的连接没有断开&＃xff0c;客户端断开连接后&＃xff0c;znode将会被删除。

1.5. 顺序znode

名称中包含Zookeeper指定顺序号的znode。若在创建znode时设置了顺序标识&＃xff0c;那么该znode被创建后&＃xff0c;名字的后边将会附加一串数字&＃xff0c;该数字是由一个单调递增的计数器来生成的。例如&＃xff0c;创建节点时传入的path是”/aa/bb”&＃xff0c;创建后的则可能是”/aa/bb0002”&＃xff0c;再次创建后是”/aa/bb0003”。

Znode的创建模式CreateMode有四种&＃xff0c;分别是&＃xff1a;EPHEMERAL&＃xff08;短暂的znode&＃xff09;、EPHEMERAL_SEQUENTIAL&＃xff08;短暂的顺序znode&＃xff09;、PERSISTENT&＃xff08;持久的znode&＃xff09;和PERSISTENT_SEQUENTIAL&＃xff08;持久的顺序znode&＃xff09;。如果您已经看过了上篇博文&＃xff0c;那么这里的api调用应该是很好理解的&＃xff0c;见&＃xff1a;http://www.cnblogs.com/leocook/p/zk_0.html。

1.6. 观察

这部分在上篇博文中已经做了详细的说明&＃xff0c;包括连接的观察和znode的观察,这部分在构建一个稳定的zookeeper应用中有着很重要的作用&＃xff0c;具体会在下边说到。

2.  ACL

即&＃xff1a;Access Control List&＃xff08;访问控制列表&＃xff09;。Znode被创建时带有一个ACL列表&＃xff0c;zk提供了下边三种身份验证模式&＃xff1a;

• digest

用户名&＃43;密码验证。

• host

客户端主机名hostname验证。

• ip

客户端的IP验证。

• auth

使用sessionID验证

• world

无验证&＃xff0c;默认是无任何权限。该模式较为特殊&＃xff0c;在给zk连接添加ACL中会说到

ACL权限对应如下表&＃xff1a;

在设置ACL时&＃xff0c;可以给zk客户端和服务器端的连接设置ACL&＃xff0c;也可以在创建znode时&＃xff0c;给znode设置ACL&＃xff0c;在创建了znode后&＃xff0c;如果有zk客户端来操作znode&＃xff0c;只有满足权限要求时&＃xff0c;才能完成相对应的操作&＃xff1a;

2.1. 给ZK连接添加ACL

可使用zk对象的addAuthInfo()方法来添加验证模式&＃xff0c;如使用digest模式进行身份验证&＃xff1a;zk.addAuthInfo(“digest”,”username:passwd”.getBytes());

在zookeeper对象被创建时&＃xff0c;初始化会被添加world验证模式。world身份验证模式的验证id是”anyone”。

若该连接创建了znode&＃xff0c;那么他将会被添加auth身份验证模式的验证id是””&＃xff0c;即空字符串&＃xff0c;这里将使用sessionID进行验证。

2.2. 给znode设置ACL

• 自己创建ACL

创建ACL对象时&＃xff0c;可用ACL类的构造方法ACL(int perms, Id id)&＃xff1a;

其中参数perms表示权限&＃xff0c;在接口org.apache.zookeeper.ZooDefs.Perms中有相关的常量&＃xff1a;READ、WRITE、CREATE、DELETE、ALL和ADMIN&＃xff0c;它们值如下表&＃xff1a;

Id参数是验证模式&＃xff0c;可用构造方法Id(String scheme, String id)来创建。参数scheme是验证模式&＃xff0c;digest、host或ip&＃xff0c;id是对应的验证&＃xff0c;digest对应用户名和密码对&＃xff0c;如“user:passwd”&＃xff1b;host对应主机名&＃xff0c;如”localhost”&＃xff1b;ip对应ip地址&＃xff0c;如”192.168.1.120”。

• 使用api中预设的ACL

在创建znode时可以设置该znode的ACL列表。接口org.apache.zookeeper.ZooDefs.Ids中有一些已经设置好的权限常量&＃xff0c;例如&＃xff1a;

(1)、OPEN_ACL_UNSAFE&＃xff1a;完全开放。事实上这里是采用了world验证模式&＃xff0c;由于每个zk连接都有world验证模式&＃xff0c;所以znode在设置了OPEN_ACL_UNSAFE时&＃xff0c;是对所有的连接开放。

(2)、CREATOR_ALL_ACL&＃xff1a;给创建该znode连接所有权限。事实上这里是采用了auth验证模式&＃xff0c;使用sessionID做验证。所以设置了CREATOR_ALL_ACL时&＃xff0c;创建该znode的连接可以对该znode做任何修改。

(3)、READ_ACL_UNSAFE&＃xff1a;所有的客户端都可读。事实上这里是采用了world验证模式&＃xff0c;由于每个zk连接都有world验证模式&＃xff0c;所以znode在设置了READ_ACL_UNSAFE时&＃xff0c;所有的连接都可以读该znode。

注&＃xff1a;红色部分是本人阅读源码的一些研究&＃xff0c;auth和world的相关描述经供参考。

3. 运行模式

Zookeeper有两种运行模式&＃xff1a;独立模式&＃xff08;standalone mode&＃xff09;和复制模式&＃xff08;replicated mode&＃xff09;。

3.1. 独立模式

只有一个zookeeper服务实例&＃xff0c;不可保证高可靠性和恢复性&＃xff0c;可在测试环境中使用&＃xff0c;生产环境不建议使用。

3.2. 复制模式

复制模式也就是集群模式&＃xff0c;有多个zookeeper实例在运行&＃xff0c;建议多个zk实例是在不同的服务器上。集群中不同zookeeper实例之间数据不停的同步。有半数以上的实例保持正常运行&＃xff0c;zk服务就能正常运行&＃xff0c;例如&＃xff1a;有5个zk实例&＃xff0c;挂了2个&＃xff0c;还剩3个&＃xff0c;依然可以正常工作&＃xff1b;如有6个zk实例&＃xff0c;挂了3个&＃xff0c;则不能正常工作。

每个znode的修改都会被复制到超过半数的机器上&＃xff0c;这样就会保证至少有一台机器会保存最新的状态&＃xff0c;其余的副本最终都会跟新到这个状态。Zookeeper为实现这个功能&＃xff0c;使用了Zab协议&＃xff0c;该协议有两个可以无限重复的阶段&＃xff1a;

• 选举领导

集群中所有的zk实例会选举出来一个“领导实例”&＃xff08;leader&＃xff09;&＃xff0c;其它实例称之为“随从实例”&＃xff08;follower&＃xff09;。如果leader出现故障&＃xff0c;其余的实例会选出一台leader&＃xff0c;并一起提供服务&＃xff0c;若之前的leader恢复正常&＃xff0c;便成为follower。选举follower是一个很快的过程&＃xff0c;性能影响不明显。

Leader主要功能是协调所有实例实现写操作的原子性&＃xff0c;即&＃xff1a;所有的写操作都会转发给leader&＃xff0c;然后leader会将更新广播给所有的follower&＃xff0c;当半数以上的实例都完成写操作后&＃xff0c;leader才会提交这个写操作&＃xff0c;随后客户端会收到写操作执行成功的响应。

• 原子广播

上边已经说到&＃xff1a;所有的写操作都会转发给leader&＃xff0c;然后leader会将更新广播给所有的follower&＃xff0c;当半数以上的实例都完成写操作后&＃xff0c;leader才会提交这个写操作&＃xff0c;随后客户端会收到写操作执行成功的响应。这么来的话&＃xff0c;就实现了客户端的写操作的原子性&＃xff0c;每个写操作要么成功要么失败。逻辑和数据库的两阶段提交协议很像。

3.3. 复制模式下的数据一致性

Znode的每次写操作都相当于数据库里的一次事务提交&＃xff0c;每个写操作都有个全局唯一的ID&＃xff0c;称为&＃xff1a;zxid&＃xff08;ZooKeeper Transaction&＃xff09;。ZooKeeper会根据写操作的zxid大小来对操作进行排序&＃xff0c;zxid小的操作会先执行。zk下边的这些特性保证了它的数据一致性&＃xff1a;

• 顺序一致性

任意客户端的写操作都会按其发送的顺序被提交。如果一个客户端把某znode的值改为a&＃xff0c;然后又把值改为b&＃xff08;后面没有其它任何修改&＃xff09;&＃xff0c;那么任何客户端在读到值为b之后都不会再读到a。

• 原子性

这一点再前面已经说了&＃xff0c;写操作只有成功和失败两种状态&＃xff0c;不存在只写了百分之多少这么一说。

• 单一系统映像

客户端只会连接host列表中状态最新的那些实例。如果正在连接到的实例挂了&＃xff0c;客户端会尝试重新连接到集群中的其他实例&＃xff0c;那么此时滞后于故障实例的其它实例都不会接收该连接请求&＃xff0c;只有和故障实例版本相同或更新的实例才接收该连接请求。

• 持久性

写操作完成之后将会被持久化存储&＃xff0c;不受服务器故障影响。

• 及时性

在对某个znode进行读操作时&＃xff0c;应该先执行sync方法&＃xff0c;使得读操作的连接所连的zk实例能与leader进行同步&＃xff0c;从而能读到最新的类容。

注意&＃xff1a;sync调用是异步的&＃xff0c;无需等待调用的返回&＃xff0c;zk服务器会保证所有后续的操作会在sync操作完成之后才执行&＃xff0c;哪怕这些操作是在执行sync之前被提交的。

4. 提高ZooKeeper应用的容错

分布式环境是很复杂的&＃xff0c;网络的不可靠、单点故障等问题都是经常发生的。那么在构建一个分布式应用程序时&＃xff0c;这些问题都是需要慎重考虑的。因此&＃xff0c;如何构建一个可复原的分布式应用将成为一个值得讨论的话题。Java api中每个异常都对应一类故障模式&＃xff0c;下边我们将会以Java api中的异常为例来讨论ZooKeeper应用程序中可能会出现的一些故障。

4.1. Java API中的一些常见异常

• InterruptedException异常

若客户端的某操作被中断&＃xff0c;则会抛出InterruptedException异常。抛出该异常时&＃xff0c;不一定是出现故障&＃xff0c;只能表明某个zookeeper操作被中断而已。

• KeeperException异常

服务器发出错误信号或是服务器存在通信故障。该类现在共有21个子类&＃xff0c; 分为3大类&＃xff1a;

 (1)、状态异常

当一个客户端对zk的某操作失败时&＃xff0c;就会出现状态异常。例如&＃xff1a;更新数据时所指定的版本号不正确就会抛出异常BadVersionException、若在短暂的znode下创建子节点则会抛出异常NoChildrenForEphemeralsException。

(2)、可恢复的异常

那些在zk会话中可以恢复的异常叫可恢复的异常。当丢失zk连接时就会抛出异常ConnectionLossException&＃xff0c;这时zk会自动尝试重新连接&＃xff0c;以确保会话的完整性。Zk无法判断ConnectionLossException异常相关的操作是否成功执行&＃xff0c;有可能出现只完成部分&＃xff0c;那么是否重新执行刚才的操作就得知道该操作是否是等幂的。

等幂操作是指一次或多次执行都会产生相同结果的操作&＃xff1b;非等幂操作是指一次或多次执行会产生不相同结果的操作。非等幂操作就不能盲目操作了。

写操作里有创建、删除、修改。在一个分布式环境中&＃xff0c;删除zk里的znode或是修改znode的数据是等幂的&＃xff0c;只有创建znode可能不是等幂的&＃xff0c;创建顺序znode就是一个非等幂的操作。

那么怎么样才能避免创建顺序znode不会出现重复创建呢&＃xff1f;下面我来展开讨论&＃xff1a;

假设的场景&＃xff1a;

客户端&＃xff1a;客户端任务是在连接到zk服务端时会只创建一个顺序znode&＃xff1b;

ConnectionLossException&＃xff1a;抛出ConnectionLossException异常重新连接后会话没有失效&＃xff0c; 但是zk无法判断创建znode的操作是否成功。

我们知道顺序znode的节点名称格式是形如”znodeName”,zk客户端和服务器端的会话有个全局唯一的sessionID&＃xff0c;我们可以把sessionID加入znode的名称中&＃xff0c;形如&＃xff1a;” znodeName”&＃xff0c;sequentialNumber是相对于父znode唯一的。这样我们在创建某个znode之前先判断一下父znode下有无名称形如” znodeName“这样字符开头的子znode&＃xff0c;就能确保每个客户端连接只创建一个znode。

这种场景会在什么时候会遇到呢&＃xff1f;在我们要实现一个分布式锁的时候&＃xff0c;核心思想之一就在这里。那么问题来了&＃xff0c;什么是分布式锁呢&＃xff1f;后面会有独立的博文来讲解关于它的代码实现。

(3)、不可恢复的异常

不可恢复的异常发生时&＃xff0c;所有的短暂znode都将会丢失&＃xff0c;只有程序中显示的重建zk连接&＃xff0c;并重建znode的状态。例如&＃xff1a;会话过期会抛出异常SessionExpiredException&＃xff0c;身份验证失败会抛出异常AuthFailedException。

(4)、异常捕捉处理

每个子类对应一种异常状态&＃xff0c;且每个子类都对应一个关于错误类型的信息代码&＃xff0c;可以通过code方法拿到。 处理该种异常有两种办法&＃xff1a;

1、通过检测错误代码&＃xff08;可调用code方法老获取&＃xff09;来确定是哪种异常&＃xff0c;再决定应该采取何种补救措施&＃xff1b;

2、通过追捕等价的KeeperException异常&＃xff0c;然后再每段捕捉代码中执行相应的操作。

4.2. 构建可靠的zookeeper应用

上面说到了zk服务器端可能出现一些网络故障或单点故障登&＃xff0c;那么怎么编写一个可靠的zk客户端程序来应对可能不稳定的zk实例呢&＃xff1f;这里我们向一个znode写数据为例&＃xff0c;来实现它&＃xff1a;

如果您是一名Java开发人员&＃xff0c;那么我觉得上面的这些代码没什么好解释的了。下边看上层调用是怎么处理的&＃xff1a;

关于编写一个可恢复的zookeeper应用&＃xff0c;这一块理解了&＃xff0c;其它地方应该就是触类旁通了。

后边就是应用zookeeper开发&＃xff0c;例如分布式配置系统、分布式锁的实现。

参考地址&＃xff1a;http://zookeeper.apache.org/doc/r3.4.6/

参考书籍&＃xff1a;《hadoop权威指南》