ZooKeeper原理及介紹

Zookeeper簡介

1.1 什麼是Zookeeper

• ZooKeeper是一個分佈式的，開放源碼的分佈式應用程序協調服務，是Google的Chubby一個開源的實現，是大數據生態中的重要組件。它是集羣的管理者，監視着集羣中各個節點的狀態根據節點提交的反饋進行下一步合理操做。最終，將簡單易用的接口和性能高效、功能穩定的系統提供給用戶。

• 它是一個爲分佈式應用提供一致性協調服務的中間件

1.2 ZooKeeper提供了什麼

• 文件系統
  • Zookeeper提供一個多層級的節點命名空間（節點稱爲znode）。與文件系統不一樣的是，這些節點均可以設置關聯的數據，而文件系統中只有文件節點能夠存放數據而目錄節點不行。Zookeeper爲了保證高吞吐和低延遲，在內存中維護了這個樹狀的目錄結構，這種特性使得Zookeeper不能用於存放大量的數據，每一個節點的存放數據上限爲1M。
• 通知機制
  • client端會對某個znode創建一個watcher事件，當該znode發生變化時，這些client會收到zk的通知，而後client能夠根據znode變化來作出業務上的改變等。

1.3 什麼是分佈式系統

• 不少臺計算機組成一個總體, 一個總體一致對外而且處理同一請求
• 內部的每臺計算機均可以相互通訊(rest/rpc)

• 客戶端到服務端的一次請求到響應結束會經歷多臺計算機

• 圖示1

• 圖示2

  ​

1.4 分佈式系統的問題

• 服務的動態註冊和發現，爲了支持高併發，OrderService被部署了4份，每一個客戶端都保存了一份服務提供者的列表，但這個列表是靜態的（在配置文件中寫死的），若是服務的提供者發生了變化，例若有些機器down了，或者又新增了OrderService的實例，客戶端根本不知道，想要獲得最新的服務提供者的URL列表，必須手工更新配置文件，很不方便。

  • 問題 : 客戶端和服務提供者的緊耦合

  • 解決方案: 解除耦合，增長一箇中間層 -- 註冊中心它保存了能提供的服務的名稱，以及URL。首先這些服務會在註冊中心進行註冊，當客戶端來查詢的時候，只須要給出名稱，註冊中心就會給出一個URL。全部的客戶端在訪問服務前，都須要向這個註冊中心進行詢問，以得到最新的地址。

  • 註冊中心能夠是樹形結構，每一個服務下面有若干節點，每一個節點表示服務的實例。

  • 註冊中心和各個服務實例直接創建Session，要求實例們按期發送心跳，一旦特定時間收不到心跳，則認爲實例掛了，刪除該實例。

• Job協調問題

  • 三個Job的功能相同，部署在三個不一樣的機器上，要求同一時刻只有一個能夠運行，也就是若是有一個宕了的話，須要在剩下的兩個中選舉出Master繼續工做

  • 因此這三個Job須要互相協調

    • 使用共享數據庫表。咱們知道數據庫主鍵不能衝突，可讓三個Job向表中插入一樣的數據，誰成功誰就是Master。缺點是若是搶到Master的Job掛了，則記錄永遠存在，其餘的Job沒法插入數據。因此必須加上按期更新的機制。

    • 讓Job在啓動以後，去註冊中心註冊，也就是建立一個樹節點，誰成功誰是Master（註冊中心必須保證只能建立成功一次）。

    • 這樣，若是節點刪除了，就開始新一輪爭搶。

• 分佈式鎖, 多臺機器上運行的不一樣的系統操做同一資源

  • 使用Master選舉的方式，讓你們去搶，誰能搶到就建立一個/distribute_lock節點，讀完之後就刪除，讓你們再來搶。缺點是某個系統可能屢次搶到，不夠公平。

  • 讓每一個系統在註冊中心的/distribute_lock下建立子節點，而後編號,每一個系統檢查本身的編號，誰的編號小認爲誰持有了鎖，好比下圖中是系統1持有了鎖

  • 系統1操做完成之後，就能夠把process_01刪除了，再建立一個新的節點 process_04。此時是process_02最小了，因此認爲系統2持有了鎖。

  • 操做完成之後也要把process_02節點刪除，建立新的節點。這時候process_03就是最小的了，能夠持有鎖了。

• 註冊中心的高可用

  • 若是註冊中心只有一臺機器，一旦掛了，整個系統就宕了。因此須要多臺機器來保證高可用性。這樣引出了新的問題，好比樹形結構須要在多臺機器之間進行同步，通訊超時了怎麼辦，如何保證樹形結構在機器之間的強一致性。

1.5 Zookeeper做用

• master節點選舉, 主節點down掉後, 從節點就會接手工做, 而且保證這個節點是惟一的,這也就是所謂首腦模式,從而保證咱們集羣是高可用的
• 統一配置文件管理, 即只須要部署一臺服務器, 則能夠把相同的配置文件同步更新到其餘全部服務器, 此操做在雲計算中用的特別多(例如修改了redis統一配置)
• 數據發佈與訂閱, 相似消息隊列MQ
• 分佈式鎖,分佈式環境中不一樣進程之間爭奪資源,相似於多進程中的鎖
• 集羣管理, 保證集羣中數據的強一致性

1.6 Zookeeper的特性

• 一致性: 數據一致性, 數據按照順序分批入庫
• 原子性: 事務要麼成功要麼失敗
• 單一視圖: 客戶端鏈接集羣中的任意zk節點, 數據都是一致的
• 可靠性:每次對zk的操做狀態都會保存在服務端
• 實時性: 客戶端能夠讀取到zk服務端的最新數據