ZooKeeper 一

工作機制

特點

* Zoookeer: 由一個leader(領導者)，多個follower(跟隨者)組成

* Leader會進行投票的發起和決議，更新系統狀態。

* follower用於接收客戶請求並向客戶端返回結果，在選舉leader過程中參與偷跑

* 集羣只要有半數以上節點存活，Zookeeper集羣就能正常服務

* 全局數據一致,每個server都保存一份相同的副本數據，client無論連接哪個sever都一樣。

* 更新請求順序進行，來自同一個client的更新請求按其發送順序以此執行。

* 數據更新是原子性，一次數據更新要麼成功，要麼失敗。

* 實時性，在一定時間範圍內，client能讀到最新數據。

數據結構

每個節點稱爲一個ZNode,每個ZNode默認存儲1MB數據，每個ZNode都可以通過其路徑唯一標識

應用場景

統一命名服務:

統一配置管理:

統一集羣管理:

服務器節點動態上下線:

軟負載均衡：

選舉機制

* 半數機制（Paxos協議）：集羣中半數以上集羣存活，集羣可用。所以zookeeper適合裝在奇數臺機器上。

* Zookeeper 只有一個leader，其他的均爲follower。

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

假設有五臺服務器組成的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一樣當小弟。

節點類型

Znode有兩種類型

短暫（ephemeral）：客戶端和服務器端斷開連接後，創建的節點自己刪除

持久（persistent）：客戶端和服務器端斷開連接後，創建的節點不刪除

Znode有四種形式的目錄節點（默認是persistent ）

（1）持久化目錄節點（PERSISTENT）

客戶端與zookeeper斷開連接後，該節點依舊存在

（2）持久化順序編號目錄節點（PERSISTENT_SEQUENTIAL）

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

（3）臨時目錄節點（EPHEMERAL）

客戶端與zookeeper斷開連接後，該節點被刪除

（4）臨時順序編號目錄節點（EPHEMERAL_SEQUENTIAL）

客戶端與zookeeper斷開連接後，該節點被刪除，只是Zookeeper給該節點名稱進行順序編號

監聽器原理

寫數據流程