機器 控制 服務器 lock 對象 一次 reat 調用 比較

1.1 ． 數據發布與訂閱（配置中心）
發布與訂閱模型，即所謂的配置中心，顧名思義就是發布者將數據發布到 ZK
節點上，供訂閱者動態獲取數據，實現配置信息的集中式管理和動態更新。
應用在啟動的時候會主動來獲取一次配置，同時，在節點上註冊一個 Watcher， 這樣一來，以後每次配置有更新的時候，都會實時通知到訂閱的客戶端，從來達 到獲取最新配置信息的目的。比如：
分布式搜索服務中，索引的元信息和服務器集群機器的節點狀態存放在 ZK 的一些指定節點，供各個客戶端訂閱使用。
註意：適合數據量很小的場景，這樣數據更新可能會比較快。
1.2 ． 命名服務(NamingService)
在分布式系統中，通過使用命名服務，客戶端應用能夠根據指定名字來獲取資源或服務的地址，提供者等信息。被命名的實體通常可以是集群中的機器，提供的服務地址，遠程對象等等——這些我們都可以統稱他們為名字（Name）。其中較為常見的就是一些分布式服務框架中的服務地址列表。通過調用 ZK 提供的創建節點的 API，能夠很容易創建一個全局唯一的 path，這個 path 就可以作為一個名稱。
阿裏巴巴集團開源的分布式服務框架 Dubbo 中使用 ZooKeeper 來作為其命名服務，維護全局的服務地址列表。
1.3 ． 分布式鎖
分布式鎖，這個主要得益於 ZooKeeper 保證了數據的強一致性。鎖服務可以
分為兩類，一個是保持獨占，另一個是控制時序。
所謂保持獨占，就是所有試圖來獲取這個鎖的客戶端，最終只有一個可以成功獲得這把鎖。通常的做法是把 zk 上的一個 znode 看作是一把鎖，通過 create
znode 的方式來實現。所有客戶端都去創建 /distribute_lock 節點，最終成功創建的那個客戶端也即擁有了這把鎖。
控制時序，就是所有試圖來獲取這個鎖的客戶端，最終都是會被安排執行，
只是有個全局時序了。做法和上面基本類似，只是這裏 /distribute_lock 已經預先存在，客戶端在它下面創建臨時有序節點（這個可以通過節點的屬性控制：
CreateMode.EPHEMERAL_SEQUENTIAL 來指定）。Zk 的父節點（/distribute_lock） 維持一份 sequence,保證子節點創建的時序性，從而也形成了每個客戶端的全局時序。

ZooKeeper 典型應用