聊聊Zookeeper的資料一致性解決方案
個人認為Zookeeper就是一個數據庫，一個分散式資料庫，一個具有檔案系統特徵的分散式資料庫，一個提供監聽機制的具有檔案系統特質的分散式資料庫。
如果跟大家聊Zookeeper，那就避不開 領導者選舉 、 CAP 、 ZAB協議 、 資料一致性 這些概念。但事實上，這些概念中最核心的是資料一致性，CAP中的C代表的就是強一致性，ZAB協議就是用來保證資料一致性的，而大家熟知的 領導者選舉只是ZAB協議中的一個階段 而已。
所以，我們直接開門見山，來直接聊一聊Zookeeper是如何保證資料一致性的。
關於Zookeeper的資料一致性的場景演示，本文就不演示了，讀者可以直接搭一個Zookeeper叢集，然後用多個客戶端連不通的ZkServer，通過不同的客戶端，去操作的不同的ZkServer，你會發現，直接被操作的ZkServer上的資料變化會被同步到叢集裡的其他ZkServer上，這就是一致性的表現。
那麼問題是， Zookeeper的這種資料一致性是怎麼實現的呢 ？
其實，我們日常生活中涉及到很多關於資料一致性的場景，比如你和你公司的小夥伴，你們可能是組員，可能是部門同事，假如你們是組員，所以你們會有組長，假設你就是組長，那麼很有可能你需要把從客戶那裡，或產品經理那裡獲得的資訊通過開會的形式告訴給你的組員，比如今天，你決定今天下午3點給組員開會，那麼你可能今天上午在你們群裡先會通知一下，會發一條資訊：“今天下午3點，開會說一下產品經理的新需求，收到請回復”，如果你看到組員都回復了，那麼你就可以準備準備下午3點正式開會了，那麼這個場景其實就是一個一致性問題，你獲得的資訊需要同步給其他組員。
好了，我們認真的來想一下這個場景。
- 首先，我們的目標是：資訊同步，資訊一致
- 其次，我們的方法是：先在群裡預先通知，然後正式開會
- 最後，我們的結果是：組內所有的組員都獲得了同樣的資訊
這個場景中有兩個角色：
- 組長
- 組員 所用的方法有兩個階段：
- 預先通知（注意，這裡組長需要看到組員的回覆，但是他並不需要去統計 是不是所有組員都回復了 ，他只需要看到 大部分組員回覆了 ，他就認為這個會可以開了）
- 正式執行
所以，我們可以想到，對於保證資料的一致性，其實有三個要素
- 需要一個領導（組長），所以需要一個領導者選舉機制
- 需要一個數據同步方法，其實就是2PC（1. 預提交，2. 收到ACK，3. 提交）
- 需要一個回覆驗證機制，過半機制驗證
這麼一分析下來，不知道大家對於一致性的解決方案有沒有自己的理解了，這裡沒有涉及到Zookeeper的原始碼分析，存理論分析，大家可以把自己的理解評論出來，一起討論。
