Apache Thrift 是 Facebook 實現的一種高效的、支持多種編程語言的遠程服務調用的框架。

目前流行的服務調用方式有很多種，例如基於 SOAP 消息格式的 Web Service，基於 JSON 消息格式的 RESTful 服務等。其中所用到的數據傳輸方式包括 XML，JSON 等，然而 XML 相對體積太大，傳輸效率低，JSON 體積較小，新穎，但還不夠完善。本文將介紹由 Facebook 開發的遠程服務調用框架 Apache Thrift，它采用接口描述語言定義並創建服務，支持可擴展的跨語言服務開發，所包含的代碼生成引擎可以在多種語言中，如 C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, Smalltalk 等創建高效的、無縫的服務，其傳輸數據采用二進制格式，相對 XML 和 JSON 體積更小，對於高並發、大數據量和多語言的環境更有優勢。

Thrift 包含一個完整的堆棧結構用於構建客戶端和服務器端。下圖描繪了 Thrift 的整體架構。

如圖所示，圖中黃色部分是用戶實現的業務邏輯，褐色部分是根據 Thrift 定義的服務接口描述文件生成的客戶端和服務器端代碼框架，紅色部分是根據 Thrift 文件生成代碼實現數據的讀寫操作。紅色部分以下是 Thrift 的傳輸體系、協議以及底層 I/O 通信，使用 Thrift 可以很方便的定義一個服務並且選擇不同的傳輸協議和傳輸層而不用重新生成代碼。

Thrift 服務器包含用於綁定協議和傳輸層的基礎架構，它提供阻塞、非阻塞、單線程和多線程的模式運行在服務器上，可以配合服務器 / 容器一起運行，可以和現有的 J2EE 服務器 /Web 容器無縫的結合。

參考鏈接：http://www.ibm.com/developerworks/cn/java/j-lo-apachethrift/

Zookeeper 分布式服務框架是 Apache Hadoop 的一個子項目，它主要是用來解決分布式應用中經常遇到的一些數據管理問題，如：統一命名服務、狀態同步服務、集群管理、分布式應用配置項的管理等。

ZooKeeper 典型的應用場景

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

下面詳細介紹這些典型的應用場景，也就是 Zookeeper 到底能幫我們解決那些問題？下面將給出答案。

統一命名服務（Name Service）

分布式應用中，通常需要有一套完整的命名規則，既能夠產生唯一的名稱又便於人識別和記住，通常情況下用樹形的名稱結構是一個理想的選擇，樹形的名稱結構是一個有層次的目錄結構，既對人友好又不會重復。說到這裏你可能想到了 JNDI，沒錯 Zookeeper 的 Name Service 與 JNDI 能夠完成的功能是差不多的，它們都是將有層次的目錄結構關聯到一定資源上，但是 Zookeeper 的 Name Service 更加是廣泛意義上的關聯，也許你並不需要將名稱關聯到特定資源上，你可能只需要一個不會重復名稱，就像數據庫中產生一個唯一的數字主鍵一樣。

Name Service 已經是 Zookeeper 內置的功能，你只要調用 Zookeeper 的 API 就能實現。如調用 create 接口就可以很容易創建一個目錄節點。

配置管理（Configuration Management）

配置的管理在分布式應用環境中很常見，例如同一個應用系統需要多臺 PC Server 運行，但是它們運行的應用系統的某些配置項是相同的，如果要修改這些相同的配置項，那麽就必須同時修改每臺運行這個應用系統的 PC Server，這樣非常麻煩而且容易出錯。

像這樣的配置信息完全可以交給 Zookeeper 來管理，將配置信息保存在 Zookeeper 的某個目錄節點中，然後將所有需要修改的應用機器監控配置信息的狀態，一旦配置信息發生變化，每臺應用機器就會收到 Zookeeper 的通知，然後從 Zookeeper 獲取新的配置信息應用到系統中。

集群管理（Group Membership）

Zookeeper 能夠很容易的實現集群管理的功能，如有多臺 Server 組成一個服務集群，那麽必須要一個“總管”知道當前集群中每臺機器的服務狀態，一旦有機器不能提供服務，集群中其它集群必須知道，從而做出調整重新分配服務策略。同樣當增加集群的服務能力時，就會增加一臺或多臺 Server，同樣也必須讓“總管”知道。

Zookeeper 不僅能夠幫你維護當前的集群中機器的服務狀態，而且能夠幫你選出一個“總管”，讓這個總管來管理集群，這就是 Zookeeper 的另一個功能 Leader Election。

它們的實現方式都是在 Zookeeper 上創建一個 EPHEMERAL 類型的目錄節點，然後每個 Server 在它們創建目錄節點的父目錄節點上調用 getChildren(String path, boolean watch) 方法並設置 watch 為 true，由於是 EPHEMERAL 目錄節點，當創建它的 Server 死去，這個目錄節點也隨之被刪除，所以 Children 將會變化，這時 getChildren上的 Watch 將會被調用，所以其它 Server 就知道已經有某臺 Server 死去了。新增 Server 也是同樣的原理。

Zookeeper 如何實現 Leader Election，也就是選出一個 Master Server。和前面的一樣每臺 Server 創建一個 EPHEMERAL 目錄節點，不同的是它還是一個 SEQUENTIAL 目錄節點，所以它是個 EPHEMERAL_SEQUENTIAL 目錄節點。之所以它是 EPHEMERAL_SEQUENTIAL 目錄節點，是因為我們可以給每臺 Server 編號，我們可以選擇當前是最小編號的 Server 為 Master，假如這個最小編號的 Server 死去，由於是 EPHEMERAL 節點，死去的 Server 對應的節點也被刪除，所以當前的節點列表中又出現一個最小編號的節點，我們就選擇這個節點為當前 Master。這樣就實現了動態選擇 Master，避免了傳統意義上單 Master 容易出現單點故障的問題。

共享鎖（Locks）

共享鎖在同一個進程中很容易實現，但是在跨進程或者在不同 Server 之間就不好實現了。Zookeeper 卻很容易實現這個功能，實現方式也是需要獲得鎖的 Server 創建一個 EPHEMERAL_SEQUENTIAL 目錄節點，然後調用 getChildren方法獲取當前的目錄節點列表中最小的目錄節點是不是就是自己創建的目錄節點，如果正是自己創建的，那麽它就獲得了這個鎖，如果不是那麽它就調用 exists(String path, boolean watch) 方法並監控 Zookeeper 上目錄節點列表的變化，一直到自己創建的節點是列表中最小編號的目錄節點，從而獲得鎖，釋放鎖很簡單，只要刪除前面它自己所創建的目錄節點就行了。

隊列管理

Zookeeper 可以處理兩種類型的隊列：

1. 當一個隊列的成員都聚齊時，這個隊列才可用，否則一直等待所有成員到達，這種是同步隊列。

2. 隊列按照 FIFO 方式進行入隊和出隊操作，例如實現生產者和消費者模型。

同步隊列用 Zookeeper 實現的實現思路如下：

創建一個父目錄 /synchronizing，每個成員都監控標誌（Set Watch）位目錄 /synchronizing/start 是否存在，然後每個成員都加入這個隊列，加入隊列的方式就是創建 /synchronizing/member_i 的臨時目錄節點，然後每個成員獲取 / synchronizing 目錄的所有目錄節點，也就是 member_i。判斷 i 的值是否已經是成員的個數，如果小於成員個數等待 /synchronizing/start 的出現，如果已經相等就創建 /synchronizing/start。

總結

Zookeeper 作為 Hadoop 項目中的一個子項目，是 Hadoop 集群管理的一個必不可少的模塊，它主要用來控制集群中的數據，如它管理 Hadoop 集群中的 NameNode，還有 Hbase 中 Master Election、Server 之間狀態同步等。

本文介紹的 Zookeeper 的基本知識，以及介紹了幾個典型的應用場景。這些都是 Zookeeper 的基本功能，最重要的是 Zoopkeeper 提供了一套很好的分布式集群管理的機制，就是它這種基於層次型的目錄樹的數據結構，並對樹中的節點進行有效管理，從而可以設計出多種多樣的分布式的數據管理模型，而不僅僅局限於上面提到的幾個常用應用場景。

參考鏈接：http://www.ibm.com/developerworks/cn/opensource/os-cn-zookeeper/

框架-thrift-zookeeper-kafka