5. 監視和ZooKeeper操作
阿新 • • 發佈：2017-11-14
設置 markdown node 點列 write head 服務器 情況 持久
ZooKeeper中的寫入（write）操作是原子性和持久性的。 寫入到大多數ZooKeeper服務器上的持久性存儲中，可以保證寫操作成功。 無論如何，ZooKeeper的最終一致性模型允許讀取（read）ZooKeeper服務的最新狀態，並且同步（sync）操作允許客戶端更新ZooKeeper服務的最新狀態。
znode中的讀取（read）操作（如exists，getChildren和getData）允許在其上設置監視。 另一方面，由znode的寫入（write）操作觸發的監視（如create，delete和setData ACL操作）並不會有監控的參與。
以下是在znode狀態更改期間可能發生的監視事件的類型：
- NodeChildrenChanged： 一個znode的子節點被創建或刪除時
- NodeCreated：在ZooKeeper路徑中創建一個znode時
- NodeDataChanged：與znode相關的數據被更新時
- NodeDeleted： znode在ZooKeeper路徑中被刪除時
監視事件的類型取決於監視和觸發監視的操作。 關於三個主要操作如何產生事件的一些關鍵信息如下表所示：
| 操作 | 事件生成操作 |
|---|---|
| exists | znode被創建或刪除，或其數據被更新 |
| getChildren | znode的子節點被創建或刪除，或者znode本身被刪除 |
| getData | znode被刪除或其數據被更新 |
監視事件包括生成事件的znode的路徑。 因此，客戶端可以通過檢查znode的路徑來找到NodeCreated和NodeDeleted事件的znode創建和刪除。 要發現NodeChildrenChanged事件後哪些子節點發生了變化，必須調用getChildren操作來檢索新的子節點列表。 同樣，為了發現NodeDataChanged事件的新數據，必須調用getData方法。
ZooKeeper從其數據模型的角度提供了一系列的保證，並在其基礎上構建了監視底層建設，從而實現了其他分布式協調原語的簡單，快速和可擴展的構建：
- Sequential consistency：這確保了客戶端的更新總是以FIFO的順序處理。
- Atomicity：這確保更新要麽成功，要麽失敗，不會有部分提交的情況。
- Single system image：客戶端可以看到ZooKeeper服務的相同視圖，它不依賴於它所連接的系統中的哪個ZooKeeper服務器。
- Reliability：這確保了這些更新一旦被應用就會一直存在。直到被客戶端重寫。
- Timeliness：客戶端的系統視圖保證在一定的時間內是最新的。這被稱為最終一致性。
5. 監視和ZooKeeper操作