Zookeeper

一、概述

Zookeeper 是一個開源的分佈式的,爲分佈式應用提供協調服務的 Apache 項目

Zookeeper 從設計模式角度來理解:是一個基於觀察者模式設計的分佈式服務管理框架,它負責存儲和管理大家都關心的數據,然後接受觀察者的註冊,一旦這些數據的狀態發生變化,Zookeeper 就將負責通知已經在 Zookeeper 上註冊的那些觀察者做出相應的反應,從而實現集羣中類似 Master/Slave 管理模式

Zookeeper=文件系統+通知機制

二、特點

  1. Zookeeper:一個領導者(leader),多個跟隨者(follower)組成的集羣。
  2. Leader負責進行投票的發起和決議,更新系統狀態
  3. Follower用於接收客戶請求並向客戶端返回結果,在選舉 Leader 過程中參與投票
  4. 集羣中只要有半數以上節點存活,Zookeeper 集羣就能正常服務。
  5. 全局數據一致:每個 server 保存一份相同的數據副本,client 無論連接到哪個 server,數據都是一致的。
  6. 更新請求順序進行,來自同一個 client 的更新請求按其發送順序依次執行。
  7. 數據更新原子性,一次數據更新要麼成功,要麼失敗。
  8. 實時性,在一定時間範圍內,client 能讀到最新數據。

 三、數據結構

ZooKeeper 數據模型的結構與 Unix 文件系統很類似,整體上可以看作是一棵樹,每個節點稱做一個 ZNode。

很顯然 zookeeper 集羣自身維護了一套數據結構。這個存儲結構是一個樹形結構,其上的每一個節點,我們稱之爲"znode",每一個 znode 默認能夠存儲 1MB 的數據,每個 ZNode都可以通過其路徑唯一標識

 四、應用場景

提供的服務包括:統一命名服務、統一配置管理、統一集羣管理、服務器節點動態上下線、軟負載均衡等。

統一命名服務

統一配置管理

 

 統一集羣管理

服務器動態上下線

 

軟負載均衡

 

五、Zookeeper內部原理

 1、選舉機制(面試重點)

1)半數機制(Paxos 協議):集羣中半數以上機器存活,集羣可用。所以 zookeeper適合裝在奇數臺機器上。

2)Zookeeper 雖然在配置文件中並沒有指定 master 和 slave。但是,zookeeper 工作時,是有一個節點爲 leader,其他則爲 follower,Leader 是通過內部的選舉機制臨時產生的

3)以一個簡單的例子來說明整個選舉的過程。

假設有五臺服務器組成的 zookeeper 集羣,它們的 id 從 1-5,同時它們都是最新啓動的,也就是沒有歷史數據,在存放數據量這一點上,都是一樣的。

假設這些服務器依序啓動,來看看會發生什麼。

(1)服務器 1 啓動,此時只有它一臺服務器啓動了,它發出去的報沒有任何響應,所以它的選舉狀態一直是 LOOKING 狀態。

(2)服務器 2 啓動,它與最開始啓動的服務器 1 進行通信,互相交換自己的選舉結果,由於兩者都沒有歷史數據,所以 id 值較大的服務器 2 勝出,但是由於沒有達到超過半數以上的服務器都同意選舉它(這個例子中的半數以上是 3),所以服務器 1、2 還是繼續保持LOOKING 狀態。

(3)服務器 3 啓動,根據前面的理論分析,服務器 3 成爲服務器 1、2、3 中的老大,而與上面不同的是,此時有三臺服務器選舉了它,所以它成爲了這次選舉的 leader。

(4)服務器 4 啓動,根據前面的分析,理論上服務器 4 應該是服務器 1、2、3、4 中最大的,但是由於前面已經有半數以上的服務器選舉了服務器 3,所以它只能接收當小弟的命了。

(5)服務器 5 啓動,同 4 一樣當小弟。

2、節點類型

 

1)Znode 有兩種類型:
短暫(ephemeral):客戶端和服務器端斷開連接後,創建的節點自己刪除
持久(persistent):客戶端和服務器端斷開連接後,創建的節點不刪除

2)Znode 有四種形式的目錄節點(默認是 persistent )
(1)持久化目錄節點(PERSISTENT)

客戶端與 zookeeper 斷開連接後,該節點依舊存在
(2)持久化順序編號目錄節點(PERSISTENT_SEQUENTIAL)

客戶端與 zookeeper 斷開連接後,該節點依舊存在,只是 Zookeeper 給該節點名稱進行順序編號

(3)臨時目錄節點(EPHEMERAL)
客戶端與 zookeeper 斷開連接後,該節點被刪除

(4)臨時順序編號目錄節點(EPHEMERAL_SEQUENTIAL)
客戶端與 zookeeper 斷開連接後,該節點被刪除,只是 Zookeeper 給該節點名稱進行順序編號

3)創建 znode 時設置順序標識,znode 名稱後會附加一個值,順序號是一個單調遞增的計數
器,由父節點維護

4)在分佈式系統中,順序號可以被用於爲所有的事件進行全局排序,這樣客戶端可以通過順序號推斷事件的順序

3、stat結構體

1) czxid- 引起這個 znode 創建的 zxid,創建節點的事務的 zxid

每次修改 ZooKeeper 狀態都會收到一個 zxid 形式的時間戳,也就是 ZooKeeper 事務 ID。

事務 ID 是 ZooKeeper 中所有修改總的次序。每個修改都有唯一的 zxid,如果 zxid1 小
於 zxid2,那麼 zxid1 在 zxid2 之前發生。
2) ctime - znode 被創建的毫秒數(從 1970 年開始)
3) mzxid - znode 最後更新的 zxid

4) mtime - znode 最後修改的毫秒數(從 1970 年開始)
5) pZxid-znode 最後更新的子節點 zxid
6) cversion - znode 子節點變化號,znode 子節點修改次數7)dataversion - znode 數據變化號

8) aclVersion - znode 訪問控制列表的變化號
9) ephemeralOwner- 如果是臨時節點,這個是 znode 擁有者的 session id。如果不是臨時節
點則是 0。
10) dataLength- znode 的數據長度
11) numChildren - znode 子節點數量

4、監聽器原理(面試重點)

1)監聽原理詳解

1)首先要有一個 main()線程

2)在 main 線程中創建 Zookeeper 客戶端,這時就會創建兩個線程,一個負責網絡連接通信(connet),一個負責監聽(listener)。

3)通過 connect 線程將註冊的監聽事件發送給 Zookeeper。

4)在 Zookeeper 的註冊監聽器列表中將註冊的監聽事件添加到列表中。

5)Zookeeper 監聽到有數據或路徑變化,就會將這個消息發送給 listener 線程。

6)listener 線程內部調用了 process()方法。

2)常見的監聽

(1)監聽節點數據的變化:

get path [watch]

(2)監聽子節點增減的變化

ls path [watch]

5、寫數據流程

客戶端向服務器提交數據,是怎麼寫的?

1)怎麼保證每個節點上的副本都是一樣的?

2)Leader和Follower是怎麼分工的,都做了什麼事情?

 

ZooKeeper 的寫數據流程主要分爲以下幾步:
1) 比如 Client 向 ZooKeeper 的 Server1 上寫數據,發送一個寫請求。

2) 如果 Server1 不是 Leader,那麼 Server1 會把接受到的請求進一步轉發給 Leader,因爲每個 ZooKeeper 的 Server 裏面有一個是 Leader。這個 Leader 會將寫請求廣播給各個Server,比如 Server1 和 Server2, 各個 Server 寫成功後就會通知 Leader。

3) 當 Leader 收到大多數 Server 數據寫成功了,那麼就說明數據寫成功了。如果這裏三個節點的話,只要有兩個節點數據寫成功了,那麼就認爲數據寫成功了。寫成功之後,Leader 會告訴 Server1 數據寫成功了。

4) Server1 會進一步通知 Client 數據寫成功了,這時就認爲整個寫操作成功。ZooKeeper整個寫數據流程就是這樣的。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章