ZooKeeper權限控制

目前在公司内部使用ZooKeeper的地方越來越多，應用大多喜歡自己部署一套ZK叢集來使用。考慮到ZK的高可用，并且一套ZK叢集至少3台機器，那麼每個應用，尤其是一些非核心應用都自己去部署一套的話，對資源使用率很低。另外，随着ZK容災的提出，單套ZK叢集使用的機器量會更大，運維人員開始對這個情況擔憂，強烈希望能夠合并ZK叢集。

ZK叢集合并使用本身并沒有太大的難度，問題在于應用方是否願意大家共用一套ZK叢集，這其中一個顯而易見的問題就是權限：如果我的資料被别人動了怎麼辦？

在公司不少牛人的幫助下，暫時得到兩個權限方案，同時也希望大家提出自己的看法，共同進步。個人建議采用zookeeperacl的權限控制方式。

這種方案将zookeeper的acl和digest授權認證模式相結合。

可以把這個通路授權過程看作是使用者注冊，系統給你一個密碼，每次操作使用這個使用者名(appName)和密碼.于是就可以對應有這樣權限管理系統，專門是負責進行節點的建立申請：包含“申請私有節點”和“申請公有節點”。這樣一來，節點的建立都是由這個權限管理系統來負責了，每次申請完後，系統都會傳回給你的一個key，格式通常是“{appName}:{password}”,以後你的任何操作都要在zksession中攜帶上這個key，這樣就能進行權限控制。當然，使用者自己通過zk用戶端進行path的建立也是可以的，隻是要求他們要使用授權方式來進行zk節點的建立。（注意，如果使用zkclient，請使用https://github.com/nileader/zkclient）

整個權限控制流程的代碼測試，如下圖所示，點選檢視大圖：（測試代碼在這裡）

這個方案大緻是這樣：

1.A系統上有一份IP和appName對應的資料本地。

2.将這份資料在ZK伺服器上緩存一份，并定時進行緩存更新。

3.每次用戶端對伺服器發起請求的時候，擷取用戶端ip進行查詢，判斷是否有對應appName的權限。限制指定ip隻能操作指定/appNameznode。

4.其它容災措施。

個人比較兩個方案：

1.方案一較方案二，使用者的掌控性大，無論線上，日常，測試都可以由應用開發人員自己決定開啟/關閉權限。（方案一的優勢）

2.方案二較方案一，易用性強，使用者的使用和無權限基本一緻。（方案二的優勢）

3.方案一較方案二更為純潔。因為我覺得zk本來就應該是一個底層元件，讓他來依賴其它上層的另一個系統？權限的控制精度取決于系統A上資訊的準确性。(方案一的優勢)

另外附上方案一有權限和無權限對比壓測TPS情況

測試條件：三台ZK伺服器：8核JDK1.6.0-06四台zk用戶端機器：5核JDK1.6.0-21

測試場景：800個釋出者，對應800個path，每個path3個訂閱者，共2400個訂閱者。釋出者釋出資料，通知訂閱者。

結論：權限控制對zk的TPS有一定的影響，但是還是保持在較高的水準（1.3w+)