目前在公司内部使用ZooKeeper的地方越来越多，应用大多喜欢自己部署一套zk环境进行使用。考虑到zk的高可用，并且一套zk集群至少3台机器，那么每个应用，尤其是一些非核心应用都自己去部署一套的话，对资源利用率很低。另外，随着ZK容灾的提出，单套ZK集群使用的机器量会更大，运维人员开始对这个情况担忧，强烈希望能够合并ZK集群。

     ZK集群合并使用本身并没有太大的难度，问题在于应用方是否愿意大家共用一套ZK集群，这其中一个显而易见的问题就是权限：如果我的数据被别人动了怎么办？

     在公司不少牛人的帮助下，暂时得到两个权限方案，同时也希望大家提出自己的看法，共同进步。

方案一：采用ZooKeeper支持的digest方式，用户自己定义节点的权限

     这种方案将zookeeper的acl和digest授权认证模式相结合。具体操作流程如下：

     可以把这个访问授权过程看作是用户注册，系统给你一个密码，每次操作使用这个用户名(appName)和密码. 于是就可以对应有这样权限管理系统，专门是负责进行节点的创建申请：包含“申请私有节点”和“申请公有节点”。这样一来，节点的创建都是由这个权限管理系统来负责了，每次申请完后，系统都会返回给你的一个key，格式通常是“{appName}:{password}”,以后你的任何操作都要在zk session 中携带上这个key，这样就能进行权限控制。当然，用户自己通过zk客户端进行path的创建也是可以的，只是要求他们要使用授权方式来进行zk节点的创建。

    整个权限控制流程的代码测试，如下图所示：

方案二、对zookeeper的AuthenticationProvider进行扩展，和内部其它系统A打通，从系统A中获取一些信息来判断权限

    这个方案大致是这样：

     1. A系统上有一份IP和appName对应的数据本地。

     2. 将这份数据在ZK服务器上缓存一份，并定时进行缓存更新。

     3. 每次客户端对服务器发起请求的时候，获取客户端ip进行查询，判断是否有对应appName的权限。限制指定ip只能操作指定 /appName znode。

     4. 其它容灾措施。

    个人比较两个方案：

     1.方案一较方案二，用户的掌控性大，无论线上，日常，测试都可以由应用开发人员自己决定开启/关闭权限。 (方案一的优势)

     2.方案二较方案一，易用性强，用户的使用和无权限基本一致。 (方案二的优势)

     3.方案一较方案二更为纯洁。因为我觉得zk本来就应该是一个底层组件，让他来依赖其它上层的另一个系统？权限的控制精度取决于系统A上信息的准确性。 (方案一的优势)

    另外附上 方案一 有权限和无权限对比压测TPS情况

     测试条件：三台ZK服务器：8核 JDK 1.6.0-06 四台zk客户端机器：5核 JDK1.6.0-21

     测试场景：800个发布者，对应800个path，每个path 3个订阅者，共2400个订阅者。发布者发布数据，通知订阅者。

     结论：权限控制对zk的TPS有一定的影响，但是还是保持在较高的水准(1.3w+)，如图(点击查看大图)：

建议继续学习：

1. Zookeeper工作原理    (阅读：10400)
2. Zookeeper研究和应用    (阅读：8521)
3. ZooKeeper典型使用场景一览    (阅读：5172)
4. ZooKeeper管理员指南——部署与管理ZooKeeper    (阅读：4822)
5. mysql 1045(28000)错误    (阅读：4637)
6. zookeeper使用和原理探究（一）    (阅读：4510)
7. 文件明明存在但是file_exists总是返回FALSE    (阅读：3951)
8. ZooKeeper解惑    (阅读：3676)
9. Linux用户、用户组、文件权限学习笔记    (阅读：3655)
10. crontab异常，无法自动运行    (阅读：3352)