初識Zookeeper

轉自：https://my.oschina.net/huangyong/blog/345164

        在 Java 世界裏，有一種技術可以實現“跨虛擬機”的調用，它就是 RMI（Remote Method Invocation，遠程方法調用）。例如，服務A 在 JVM1 中運行，服務B 在 JVM2 中運行，服務A 與 服務B 可相互進行遠程調用，就像調用本地方法一樣，這就是 RMI。在分佈式系統中，我們使用 RMI 技術可輕鬆將 服務提供者（Service Provider）與 服務消費者（Service Consumer）進行分離，充分體現組件之間的弱耦合，系統架構更易於擴展。使用 ZooKeeper 可輕鬆解決 RMI 調用過程中所涉及的問題。

         ZooKeeper 是 Hadoop 的一個子項目，用於解決分佈式系統之間的數據一致性問題，如果讀者尚不瞭解 ZooKeeper 的工作原理與使用方法，可以通過以下鏈接來了解：

• ZooKeeper 官網
• 分佈式服務框架 ZooKeeper -- 管理分佈式環境中的數據

        本文假設讀者已經對 ZooKeeper 有一定了解的前提下，對 RMI 的高可用性問題提供一個簡單的解決方案。

        要想解決 RMI 服務的高可用性問題，我們需要利用 ZooKeeper 充當一個 服務註冊表（Service Registry），讓多個 服務提供者（Service Provider）形成一個集羣，讓 服務消費者（Service Consumer）通過服務註冊表獲取具體的服務訪問地址（也就是 RMI 服務地址）去訪問具體的服務提供者。如下圖所示：

需要注意的是，服務註冊表並不是 Load Balancer（負載均衡器），提供的不是“反向代理”服務，而是“服務註冊”與“心跳檢測”功能。

利用服務註冊表來註冊 RMI 地址，這個很好理解，那麼“心跳檢測”又如何理解呢？說白了就是通過服務中心定時向各個服務提供者發送一個請求（實際上建立的是一個 Socket 長連接），如果長期沒有響應，服務中心就認爲該服務提供者已經“掛了”，只會從還“活着”的服務提供者中選出一個做爲當前的服務提供者。

也許讀者會考慮到，服務中心可能會出現單點故障，如果服務註冊表都壞掉了，整個系統也就癱瘓了。看來要想實現這個架構，必須保證服務中心也具備高可用性。

ZooKeeper 正好能夠滿足我們上面提到的所有需求。

1. 使用 ZooKeeper 的臨時性 ZNode 來存放服務提供者的 RMI 地址，一旦與服務提供者的 Session 中斷，會自動清除相應的 ZNode。
2. 讓服務消費者去監聽這些 ZNode，一旦發現 ZNode 的數據（RMI 地址）有變化，就會重新獲取一份有效數據的拷貝。
3. ZooKeeper 與生俱來的集羣能力（例如：數據同步與領導選舉特性），可以確保服務註冊表的高可用性。

        通過本文，我們嘗試使用 ZooKeeper 實現了一個簡單的 RMI 服務高可用性解決方案，通過 ZooKeeper 註冊所有服務提供者發佈的 RMI 服務，讓服務消費者監聽 ZooKeeper 的 Znode，從而獲取當前可用的 RMI 服務。此方案侷限於 RMI 服務，對於任何形式的服務（比如：WebService），也提供了一定參考。

        總結： ZooKeeper從設計模式角度來看，是一個基於服務提供者（Service Provider）模式設計的分佈式服務管理框架，它負責存儲和管理大家都關心的數據，然後接受服務提供者（Service Provider）的註冊，一旦這些數據的狀態發生變化，Zookeeper 就將負責通知已經在 Zookeeper 上註冊的那些服務提供者（Service Provider）做出相應的反應，從而實現集羣中類似 Master/Slave 管理模式，關於 Zookeeper 的詳細架構等內部細節可以閱讀 Zookeeper 的源碼。