zookeeper注意事项

一、使用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.