聊聊Zookeeper的數據一致性解決方案

我的認爲Zookeeper就是一個數據庫，一個分佈式數據庫，一個具備文件系統特徵的分佈式數據庫，一個提供監聽機制的具備文件系統特質的分佈式數據庫。

若是跟你們聊Zookeeper，那就避不開領導者選舉、CAP、ZAB協議、數據一致性這些概念。但事實上，這些概念中最核心的是數據一致性，CAP中的C表明的就是強一致性，ZAB協議就是用來保證數據一致性的，而你們熟知的領導者選舉只是ZAB協議中的一個階段而已。

因此，咱們直接開門見山，來直接聊一聊Zookeeper是如何保證數據一致性的。

關於Zookeeper的數據一致性的場景演示，本文就不演示了，讀者能夠直接搭一個Zookeeper集羣，而後用多個客戶端連不通的ZkServer，經過不一樣的客戶端，去操做的不一樣的ZkServer，你會發現，直接被操做的ZkServer上的數據變化會被同步到集羣裏的其餘ZkServer上，這就是一致性的表現。

那麼問題是，Zookeeper的這種數據一致性是怎麼實現的呢？

其實，咱們平常生活中涉及到不少關於數據一致性的場景，好比你和你公司的小夥伴，大家多是組員，多是部門同事，假如大家是組員，因此大家會有組長，假設你就是組長，那麼頗有可能你須要把從客戶那裏，或產品經理那裏得到的信息經過開會的形式告訴給你的組員，好比今天，你決定今天下午3點給組員開會，那麼你可能今天上午在大家羣裏先會通知一下，會發一條信息：「今天下午3點，開會說一下產品經理的新需求，收到請回復」，若是你看到組員都回復了，那麼你就能夠準備準備下午3點正式開會了，那麼這個場景其實就是一個一致性問題，你得到的信息須要同步給其餘組員。

好了，咱們認真的來想一下這個場景。

• 首先，咱們的目標是：信息同步，信息一致
• 其次，咱們的方法是：先在羣裏預先通知，而後正式開會
• 最後，咱們的結果是：組內全部的組員都得到了一樣的信息

這個場景中有兩個角色：

1. 組長
2. 組員 所用的方法有兩個階段：
3. 預先通知（注意，這裏組長鬚要看到組員的回覆，可是他並不須要去統計是否是全部組員都回復了，他只須要看到大部分組員回覆了，他就認爲這個會能夠開了）
4. 正式執行

因此，咱們能夠想到，對於保證數據的一致性，其實有三個要素

1. 須要一個領導（組長），因此須要一個領導者選舉機制
2. 須要一個數據同步方法，其實就是2PC（1. 預提交，2. 收到ACK，3. 提交）
3. 須要一個回覆驗證機制，過半機制驗證

這麼一分析下來，不知道你們對於一致性的解決方案有沒有本身的理解了，這裏沒有涉及到Zookeeper的源碼分析，存理論分析，你們能夠把本身的理解評論出來，一塊兒討論。