承接上一篇：继续接受最后一个特性：ACL-保障数据的安全；
Zookeeper提供了一套完善的ACL(Access Control List)权限控制机制来保证数据的安全；
标识一个有效的ACL的三个维度：权限模式(Scheme)，授权对象(ID)，权限(Permission),通常使用 scheme:id:premission来标识一个有效的ACL；
<1> 权限模式：Scheme
1）IP模式，类似 ip:192.168.0.110 形式
2）Digest：类似于username:password 形式的；
3）World：最开放的权限控制模式，从其名字中可以看出，数据节点的访问权限对所有用户抗法。也可以将其看做是一种特殊的Digest模式，他只有一个标识，“”world:anyone”;
4）Super: 超级用户对任意zk节点进行任何操作；
<2> 授权对象：ID
授权对象是指权限赋予的用户或者一个指定实体，不同的权限模式下，授权对象是不同的。他们的对应关系：
IP -----> IP段：“192.168.0.1”
Digest -------> username:BASE64(SHA-1(username:password)),即Zookeeper会对username和password进行两次编码处理。
World------->只有一个ID:anyone；
Super-------> 与Digest模式一样；
<3> 权限：Permission
所有数据的操作权限分为五大类：
CREATE(C) : 数据节点的创建权限，允许授权对象在该数据节点下创建子节点；
DELETE(D)：子节点的删除权限；
READ(D) : 数据节点的读取权限，允许授权对象访问该数据节点并读取器数据内容或子节点列表等；
WRITE(W) ：数据节点的更新权限，允许授权对象对该数据节点机进行更新；
ADMIN(A) : 数据节点的管理权限，允许授权对象对该数据节点进行ACL相关的设置操作；
权限扩展：
<1>实现自定义权限控制器：
权限控制器接口：AuthenticationProvider，用户可以基于该接口自定义权限控制器实现；
前面的几个模式，对应的就是Zookeeper自带的DigestAuthenticationProvider和IPAuthenticationProvider；
<2> 注册自定义权限控制器：
1）系统属性：在Zookeeper启动参数中配置：-Dzookeeper.authProvider.X = 类路径；
2）配置文件方式：在zoo.cfg配置文件中配置类似如下的配置项
对于权限控制器的注册，Zookeeper采用了延迟加载的策略，即只有在第一次处理包含权限控制的客户端请求的时候，才会进行权限控制器的初始化。
所有的权限控制器会注册到ProviderRegistry中；
<3> ACL管理：使用create 命令，或者setAcl命令；
<4> Spuer模式的用法：
问题：根据ACL权限控制的原理，一旦对一个数据节点设置了ACL权限控制，那么其他没有被授权的Zookeeper客户单将无法访问该数据节点，当一个持久节点具有ACL滞后，但其创建者已经退出或者已经不再使用，那么如何处理这些节点？
这就需要在ACL的super模式下，使用超级管理员权限处理；要使用超级权限就是在ZK启动的时候，添加：
-Dzookeeper.DigestAuthenticationProvider.superDigest=foo:kwn6anbsjskw………
到此：Zookeeper的系统模型就介绍完了，个人建议:搭一个Zookeeper环境，然后引入zk客户端依赖；对照源码学习；
后面继续介绍序列化与协议；