內容不涉及演算法相關內容,paxos演算法,zab協議等網路上已經有很多優秀的文章,這裡就不獻醜了

什麼是Zookeeper

ZooKeeper是分散式應用程式的分散式協調服務，是Google的Chubby一個開源的實現，是Hadoop和Hbase的重要組件。它是一個為分散式應用提供一致性服務的軟體，提供的功能包括：配置維護、功能變數名稱服務、分散式同步、集群管理等

為什麼需要zookeeper

隨著業務發展,單機系統處理能力達到上限,就需要對系統進行擴展,假設我們需要將資料庫擴展為主從結構,客戶端需要知道資料庫節點中主節點的位置,而當主節點發生故障時我們需要將從節點設置為新的主節點,就像redis一樣,類似的場景有很多; 而在分散式系統中,需要協調的信息很多,比如某個服務的地址,狀態,服務的名稱,或是集群間狀態同步等等......

若不使用zookeeper:

解決辦法也簡單,比如使用一個map來存儲相關的信息,需要訪問的時候從記憶體中取出即可,但由於信息可能需要在不同機器的進程中共用,還需要編寫socket通訊,另一方面這樣的方式存在單點故障,如果存儲信息的伺服器宕機,整個系統全部癱瘓;

為瞭解決單點故障,需要將這個存儲信息的服務設計為分散式的;但是這又產生了新的問題,數據如何在分散式系統中保持一致?

這就需要一致性演算法Paxos來保證,而由於Paxos存在活鎖問題zookeeper使用ZAB協議來同步數據,並保證了一致性;

zookeeper為我們實現了上述的數據存儲,分散式服務,高可用性等基礎功能,利用zookeeper可以很方便的協調分散式應用程式;

使用場景

zookeeper的使用場景比較多,以下例舉其最常用的場景

服務註冊/訂閱

在分散式服務中,通常都需要使用統一的命名,即將一些複雜不方便記憶,容易出錯的信息對應到一個唯一的簡潔的名稱,zookeeper可以很容易實現名稱的唯一性,併在這個唯一的名稱下存儲一些數據;在訪問提供方啟動後將信息放到zookeeper中,客戶端通過相同的服務名稱從zookeeper訂閱需要的服務名稱,從而獲取服務提供方的信息

配置管理(Configuration Management)

在分散式系統中經常有某些服務的調用非常頻繁,由於單點壓力大所以將其部署為集群,當需要對這個服務的配置進行修改時,以往需要逐個修改,效率低且容易出錯,得益於zookeeper提供的watch(監視)機制可以實現集中式配置管理,當配置發生變化zookeeper可以通知所有節點,這樣節點就可以訪問zookeeper獲取並應用最新的配置;

組管理(Group Management)

當需要自己搭建主從結構時,需要能夠選舉出master,同時當slave上線或是下線時master能夠立即感知(利用臨時順序節點,選取最小作為master);當master宕機後,slave要選出新的master,並通知其他slave(利用watch機制實現)

分散式鎖(Distribution Lock)

在同一臺機器實現互斥鎖是比較簡單的,因為線程或進程之間可以直接利用記憶體或文件進行狀態的同步,但是在分散式環境中,進程運行在不同的計算節點上,無法像單機那樣直接通過記憶體同步,利用zookeeper的watch,多個進程可以監視同一個數據(代表鎖),當數據狀態發生變化時進程可以知道當前鎖的狀態;

zookeeper的特性

高可用

ZooKeeper已實現主從複製。像它協調的分散式進程一樣，ZooKeeper本身也可以在一組主機上進行主從複製。從而避免單點故障並提高性能；

組成ZooKeeper集群的伺服器都彼此瞭解。它們共同維護記憶體中的數據，以及持久存儲中的事務日誌和快照。只要及群眾大多數伺服器可用，ZooKeeper服務將可用。

客戶端連接到單個ZooKeeper伺服器。客戶端維護一個TCP連接，通過它發送請求，獲取響應，獲取監視事件併發送心跳檢測。如果與伺服器的TCP連接斷開，客戶端將連接到其他伺服器。

高性能

在“讀取為主”的工作負載中，zookeeper非常快。ZooKeeper應用程式可在數千台電腦上運行，並且在讀取比寫入更為常見的情況下，其性能最佳，比率約為10：1。

提供的保證

• 順序一致性-來自客戶端的更新將按照其發送順序進行處理。
• 原子性-更新成功或失敗。不會產生部分結果。
• 單個數據視圖-無論客戶端連接到哪個伺服器，客戶端都將看到相同的數據視圖。也就是說，即使客戶端故障轉移到具有相同會話的其他伺服器，客戶端也永遠不會看到系統的較舊數據。(一致性體現)
• 可靠性-數據被更新後，此更新將一直持續到客戶端重新覆蓋更新為止，否則將永久生效
• 及時性-確保系統的客戶看到的數據在特定時間範圍內是最新的。（最終一致性）

zookeeper的相關概念

1.節點znode

Zookeeper會保存任務的分配、完成情況，等共用信息，那麼ZooKeeper是如何保存的呢?在 ZooKeeper中，這些信息被保存在一個個數據節點上，這些節點被稱為znode。它採用了類似文件系統 的層級樹狀結構進行管理。見下圖示例:

根節點/包含4個子節點，其中三個擁有下一級節點。有的葉子節點存儲了信息。 節點上沒有存儲數據，也有著重要的含義。比如在主從模式中，當/master節點沒有數據時，代表分散式應用的主節點還沒有選舉出來。

znode節點存儲的數據為位元組數組bytes。存儲數據的格式zookeeper不做限制，也不提供解析，需要應用自 己實現。

持久節點

持久節點只能通過delete刪除。zookeeper會將操作以日誌的形式寫入到磁碟,當日誌變大時，會將所有znodes當前狀態的快照寫入文件系統，並生成新的事務日誌文件;當zookeeper啟動時將從日誌恢複數據;

臨時節點

臨時節點在創建該節點的客戶端崩潰或關閉時，自動被刪除。在當前版本，由於臨時znode會因為創建者會話過期被刪 除，所以不允許臨時節點擁有子節點。

前面 例子中的/master應該使用臨時節點，這樣當主節點失效或者退出時，該znode被刪除，其他節點 知道主節點崩潰了，開始進行選舉的邏輯。另外/works/worker-1也應該是臨時節點，在此從節點 失效的時候，該臨時節點自動刪除。

節點版本

Znodes還維護一個數據結構，其中包括用於數據更改，ACL(訪問控制列表)更改和時間戳的版本號，znode的數據每次更改時，版本號都會增加。例如，每當客戶端檢索數據時，會接收數據的版本。當客戶端發起寫入操作時則需提供與伺服器上一致的版本號,否則將更新失敗;

每個znode上的數據都被原子地讀取和寫入。讀取操作將獲取與znode關聯的所有數據，而寫入將替換所有數據。每個節點都有一個訪問控制列表（ACL），用於限制誰可以執行操作。

有序節點

znode可以被設置為有序(sequential)節點。有序znode節點被分配唯一一個單調遞增的序號。 序號的格式為％010d，即10位數字，不足的填充為0，零如果創建了個一有序節點為/workers/worker-，zookeeper會自動分配一個序號1，追加在名字後面，znode名稱為/workers/worker-0000000001。通過這種方式，可以創建唯一名稱znode，並且可以直觀 的看到創建的順序。

znode常見操作及暴露的API:

• ls /path 查看節點的所有子節點
• create /path data :創建一個名為/path的znode，數據為data。
  • -e 臨時節點(當前客戶端關閉後/或當前節點重啟後失效)
  • -s 有序節點(在節點名稱後面添加節點自增的序號)
• set /path data :設置名為/path的znode的數據為data
• get /path :返回名為/path的znode的數據、

API

• delete：刪除節點
• exists：測試某個位置是否存在節點
• get children ：獲取節點子節點的列表
• sync：等待數據在所用節點完成同步

註意：上述列出的指令部分用於zkCli部分用於javaAPI;

2.觀察與通知（watch）

分散式應用需要及時知道zookeeper中znode的變化，從而瞭解到分散式應用整體的狀況，如果採用輪 詢方式，代價太大，絕大多數查詢都是無效的。因此，zookeeper採用了通知的機制。客戶端向 zookeeper請求，在特定的znode設置觀察點(watcher)。Watcher是Zookeeper中的一個很重要的 特性。Zookeeper允許用戶在指定節點上註冊一些Watcher，並且在一些特定事件觸發的時候， ZooKeeper服務端會將事件通知到感興趣的客戶端上去，該機制是Zookeeper實現分散式協調服務的重要支撐。、

wtahc的主要特性：

• 當監聽器監聽的事件被觸發,服務端會發送通知給客戶端,但通知信息中不包括事件的具體內容。以監聽ZNode結點數據變化為例,當Znode的數據被改變,客戶端會收到事件類型為 NodeDataChanged的通知,但該Znode的數據改變成了什麼客戶端無法從通知中獲取,需要客戶端 在收到通知後手動去獲取。
• Watcher是一次性的。一旦被觸發將會失效。
• 3.6.0中的新增功：客戶端可以在znode上設置永久性的監視，這些監視在觸發時不會刪除，並且會以遞歸方式觸發註冊znode以及所有子znode的通知。