一、使用ACL
对于zookeeper,开发人员往往负责访问控制的权限,而不是管理员。这是因为每次创建znode节点,必须设置访问权限,而子节点并不会继承父节点的访问权限。访问权限的检查是基于每一个znode节点的。
zookeeper通过访问控制表来控制访问权限。一个ACL包括以下形式的记录:schema:auth-info。
zookeeper通过检查客户端进程访问每个节点 时提交上来的授权信息来保证安全性。如果一个进程没有提供鉴权信息或者不匹配,那么就会进程收到权限错误。
1.内置的鉴权模式
(1)OPEN_ACL_UNSAFE
它通过常量隐式的传递了ACL策略,这种ACL使用world作为鉴权模式,使用anyone作为auth-info,对于world这种鉴权模式只等使用anyone这种auth-info
(2)super模式
该模式不会被列入到任何ACL中但可以用于鉴权。一个客户端通过super鉴权模式连接到zookeeper后,不会被任何节点的ACL所限制。
(3)digest
该模式的格式位userid:passwd_digest,当调用addAuthInfo需要设置ACL和userid:password信息。其中passwd_digest为用户密码的加密摘要。
(4)ip鉴权模式
给模式需要提供网络的地址和掩码,因为需要通过客户端的地址来进行ACL策略的检查,客户端在使用ip模式的ACL策略访问znode节点时不需要调用addAuthInfo方法
2.SASL和kerberos
在前面的方法中,如果新的开发人员加入或离开组,管理员就需要改变所有的ACL策略,如果我们通过组来避免这种情况,事情就会好一点。我们可以使用sasl模式来解决这些问题。SASL表示简单认证与安全层。 SASL将底层的鉴权模型抽象为一个框架,因此程序可以使用SASL框架,并使用支持的各种协议。在zookeeper中,SASL常常使用kerberos协议,该鉴权协议提供之前我们提到的哪些缺失的功能。在使用SASL模式中,使用sasl作为模式名,id使用kerberos的ID
二、恢复会话
假如客户端发生崩溃,之后恢复运行,应用程序还处于客户端崩溃的状态,其它客户端也许修改了zookeeper的状态,建议客户端不要使用任何之前获取的缓存状态。另一方面客户恢复时也许需要进行一些zookeeper的状态清理操作,以便完成某些未完成的任务。
三、顺序性保
虽然zookeeper会声明对一个会话中所有客户端提供顺序性的保证,但还是会出现控制之外的某些情况。
1.连接丢失时的顺序性
对于连接丢失事件,zookeeper会取消等待中的请求,对于同步方法的调用客户端库会抛出异常,对于异步请求调用,客户端调用的回调函数会返回接过来标识连接丢失。在应用程序丢失后, 客户端库不会再重新提交请求,因此就需要应用程序对已经已经取消的请求重新进行提交的操作。所以在连接丢失的情况下,可以通过客户端库来解决所有后续的操作。
2.同步API和多线程的顺序性
如果在多线程中使用同步API,需要注意顺序性问题。一个同步zookeeper调用会阻塞运行,直到响应信息。
3.同步和异步混用的顺序性
当通过异步操作提交了两个请求,AOP1和AOP2,假如在AOP1的回调函数中,调用了了一个同步函数SOP1,那么最终的顺序是AOP1,SOP1,AOP1.