本文轉自 https://www.cnblogs.com/bangerlee/p/5268485.html

本系列文章將整理到我在GitHub上的《Java面試指南》倉庫，更多精彩內容請到我的倉庫裡檢視
> https://github.com/h2pl/Java-Tutorial

喜歡的話麻煩點下Star哈

文章首發於我的個人部落格：
> www.how2playlife.com

該系列博文會告訴你什麼是分散式系統，這對後端工程師來說是很重要的一門學問，我們會逐步瞭解分散式理論中的基本概念，常見演算法、以及一些較為複雜的分散式原理，同時也需要進一步瞭解zookeeper的實現，以及CAP、一致性原理等一些常見的分散式理論基礎，以便讓你更完整地瞭解分散式理論的基礎，為後續學習分散式技術內容做好準備。

如果對本系列文章有什麼建議，或者是有什麼疑問的話，也可以關注公眾號【Java技術江湖】聯絡作者，歡迎你參與本系列博文的創作和修訂。

## [分散式服務協調員zookeeper - 應用場景和監控](https://www.cnblogs.com/bangerlee/p/4427331.html)

zookeeper在分散式系統中作為協調員的角色，可應用於Leader選舉、分散式鎖、配置管理等服務的實現。以下我們從zookeeper供的API、應用場景和監控三方面學習和了解zookeeper（以下簡稱ZK）。

**ZK API**

ZK以Unix檔案系統樹結構的形式管理儲存的資料，圖示如下：

![](https://images0.cnblogs.com/blog2015/116770/201504/142337054797921.png)

其中每個樹節點被稱為**znode**，每個znode類似一個檔案，包含檔案元資訊(meta data)和資料。

以下我們用**server**表示ZK服務的提供方，**client**表示ZK服務的使用方，當client連線ZK時，相應建立**session**會話資訊。

有兩種型別的znode：

**Regular**: 該型別znode只能由client端顯式建立或刪除

**Ephemeral**: client端可建立或刪除該型別znode；當session終止時，ZK亦會刪除該型別znode

znode建立時還可以被打上**sequential**標誌，被打上該標誌的znode，將自行加上自增的數字字尾

ZK提供了以下API，供client操作znode和znode中儲存的資料：

*   create(path, data, flags)：建立路徑為path的znode，在其中儲存data[]資料，flags可設定為Regular或Ephemeral，並可選打上sequential標誌。
*   delete(path, version)：刪除相應path/version的znode
*   exists(path,watch)：如果存在path對應znode，則返回true；否則返回false，watch標誌可設定監聽事件
*   getData(path, watch)：返回對應znode的資料和元資訊（如version等）
*   setData(path, data, version)：將data[]資料寫入對應path/version的znode
*   getChildren(path, watch)：返回指定znode的子節點集合

**ZK應用場景**

基於以上ZK提供的znode和znode資料的操作，可輕鬆實現Leader選舉、分散式鎖、配置管理等服務。

**Leader選舉**

利用打上sequential標誌的Ephemeral，我們可以實現Leader選舉。假設需要從三個client中選取Leader，實現過程如下：

**1**、各自建立Ephemeral型別的znode，並打上sequential標誌：

<pre>[zk: localhost:2181(CONNECTED) 4] ls /master
[lock-0000000241, lock-0000000243, lock-0000000242]</pre>

**2**、檢查 /master 路徑下的所有znode，如果自己建立的znode序號最小，則認為自己是Leader；否則記錄序號比自己次小的znode

**3**、非Leader在次小序號znode上設定監聽事件，並重復執行以上步驟2

假如以上 /master/lock-0000000241節點被刪除（相應client服務異常或網路異常等原因），那麼 /master/lock-0000000242相應的znode將提升自己為Leader。client只關心自己建立的znode和序號次小的znode，這避免了驚群效應(Herd Effect)。

分散式鎖的實現與以上Leader選舉的實現相同，稍作修改，我們還可以基於ZK實現lease機制（有期限的授權服務）。

**配置管理**

znode可以儲存資料，基於這一點，我們可以用ZK實現分散式系統的配置管理，假設有服務A，A擴容裝置時需要將相應新增的ip/port同步到全網伺服器的A.conf配置，實現過程如下：

**1**、A擴容時，相應在ZK上新增znode，該znode資料形式如下：

<pre>[zk: localhost:2181(CONNECTED) 30] get /A/blk-0000340369 {"svr_info": [{"ip": "1.1.1.1.", "port": "11000"}]}
cZxid = 0x2ffdeda3be ……</pre>

**2**、全網機器監聽 /A，當該znode下有新節點加入時，呼叫相應處理函式，將服務A的新增ip/port加入A.conf

**3**、完成步驟2後，繼續設定對 /A監聽

服務縮容的步驟類似，機器下線時將ZK相應節點刪除，全網機器監聽到該事件後將配置中的裝置剔除。

**ZK監控**

ZK自身提供了一些“四字命令”，透過這些四字命令，我們可以獲得ZK叢集中，某臺ZK的角色、znode數、健康狀態等資訊：

<pre># echo "mntr" | /usr/bin/netcat 127.0.0.1 2181 zk_version 3.4.3-1240972, built on 02/06/2012 10:48 GMT
zk_packets_received 267044485 zk_packets_sent 267069992 zk_outstanding_requests 0 zk_server_state follower
zk_znode_count 16216</pre>

常用的四字命令有：

*   **mntr**：顯示自身角色、znode數、平均呼叫耗時、收包發包數等資訊
*   **ruok**：診斷自身狀態是否ok
*   **cons**：展示當前的client連線

像不能問一個醉酒的人是否喝醉一樣，我們也不能確信一臺回覆"imok"的ZK就是真的ok，我們可以透過ZK自帶的zkCli.sh模擬client建立/刪除znode：

<pre>/usr/local/zookeeper/bin/zkCli.sh create /zookeeper/test 'test' >/dev/null 2>&1
/usr/local/zookeeper/bin/zkCli.sh delete /zookeeper/test >/dev/null 2>&1</pre>

再根據返回值判斷新增、刪除znode是否成功，從而判斷該臺ZK狀態是否正常。

**小結**

zookeeper以目錄樹的形式管理資料，提供znode監聽、資料設定等介面，基於這些介面，我們可以實現Leader選舉、配置管理、命名服務等功能。結合四字命令，加上模擬zookeeper client 建立/刪除znode，我們可以實現對zookeeper的有效監控。在各種分散式系統中，我們經常可以看到zookeeper的身影。

分散式系統理論基礎8：zookeeper分散式協調服務

相關文章