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服務端的最新數據