目錄
1 ZooKeeper簡介
Zookeeper: 是一個分佈式的、開源的程序協調服。他提供的主要功 能包括：配置管理、名字服務、分佈式鎖、集羣管理。具體如下：
- 配置管理：爲了集中管理配置，使用 Zab 這種一致性協議來提供一致性。
- 名字服務：使用域名代替IP統一管理服務入口，簡化了維護。
- 分佈式鎖：使用leader 選舉算法讓某個時刻只讓一個服務去幹活，當這臺服務出問題的時候鎖釋放，立即 fail over 到另外的服務。
- 集羣管理：爲了及時感知到集羣中的各種故障鎖導致的變化。
2 ZooKeeper基本概念
ZooKeeper並不直接暴露分佈式服務所需要的原語及原語的調用方法。什麼是原語？舉個例子，比如說分佈式鎖機制是一個原語，它會暴露出創建、獲取、釋放三個調用方法。ZooKeeper以類似文件系統的方式存儲數據，暴漏出調用這些數據的API。讓應用通過ZooKeeper的機制和API，自己來實現分佈式相關原語。
2.1 文件系統
Zookeeper提供一個多層級的節點命名空間（節點稱爲znode）。與文件系統不同的是，這些節點都可以設置關聯的數據，而文件系統中只有文件節點可以存放數據而目錄節點不行。Zookeeper爲了保證高吞吐和低延遲，在內存中維護了這個樹狀的目錄結構，這種特性使得Zookeeper不能用於存放大量的數據，每個節點的存放數據上限爲1M。znode如下圖所示：
根節點/包含4個子節點，其中三個擁有下一級節點。有的葉子節點存儲了信息，主要如下：
- /master，存儲了當前主節點的信息
- /workers，下面的每個子znode代表一個從節點，子znode上存儲的數據，如“foo.com:2181”，代表從節點的信息。
- /tasks，下面的每個子znode代表一個任務，子znode上存儲的信息如“run cmd”，代表該內務內容
- /assign，下面每個子znode代表一個從節點的任務集合。如/assign/worker-1，代表worker-1這個從節點的任務集合。/assign/worker-1下的每個子znode代表分配給worker-1的一個任務。
持久節點（persistent）和臨時節點（ephemeral）
持久節點只能通過delete刪除。臨時節點在創建該節點的客戶端崩潰或關閉時，自動被刪除。
前面例子中的/master應該使用臨時節點，這樣當主節點失效或者退出時，該znode被刪除，其他節點知道主節點崩潰了，開始進行選舉的邏輯。另外/works/worker-1也應該是臨時節點，在此從節點失效的時候，該臨時節點自動刪除。
在目前的版本，由於臨時znode會因爲創建者會話過期被刪除，所以不允許臨時節點擁有子節點。
有序節點
znode可以被設置爲有序（sequential）節點。有序znode節點被分配唯一一個單調遞增的證書。如果創建了個一有序節點爲/workers/worker-，zookeeper會自動分配一個序號1，追加在名字後面，znode名稱爲/workers/worker-1。通過這種方式，可以創建唯一名稱znode，並且可以直觀的看到創建的順序。
znode支持的操作及暴露的API：
create /path data //創建一個名爲/path的znode，數據爲data。
delete /path //刪除名爲/path的znode。
exists /path //檢查是否存在名爲/path的znode
setData /path data //設置名爲/path的znode的數據爲data
getData /path //返回名爲/path的znode的數據
getChildren /path //返回所有/path節點的所有子節點列表
2.2 通知機制
client端會對某個znode建立一個watcher事件，當該znode發生變化時，這些client會收到zk的通知，然後client可以根據znode變化來做出業務上的改變等。
場景分析：
- 客戶端C1設置觀察點在/tasks
- /tasks上發生了連續兩次更新
- C1在得到第一次更新的通知後就讀取了/tasks的數據
- 此時第二次更新也已經發生，C1用第一次的通知，讀取到兩次更新後的數據
此時C1雖然錯過了第二次通知，但是C1最終還是讀取到了最新的數據。
因此Zookeeper只能保證最終的一致性，而無法保證強一致性。
zookeeper可以定義不同的觀察類型。例如觀察znode數據變化，觀察znode子節點變化，觀察znode創建或者刪除。
3 分佈式系統的問題
3.1 服務的動態註冊和發現
爲了解除客戶端與服務端耦合，增加一箇中間層 -- 註冊中心它保存了能提供的服務的名稱，以及URL。首先這些服務會在註冊中心進行註冊，當客戶端來查詢的時候，只需要給出名稱，註冊中心就會給出一個URL。所有的客戶端在訪問服務前，都需要向這個註冊中心進行詢問，以獲得最新的地址。
- 註冊中心可以是樹形結構，每個服務下面有若干節點，每個節點表示服務的實例。
- 註冊中心和各個服務實例直接建立Session，要求實例們定期發送心跳，一旦特定時間收不到心跳，則認爲實例掛了，刪除該實例。
3.2 Job協調問題
三個Job的功能相同，部署在三個不同的機器上，要求同一時刻只有一個可以運行，也就是如果有一個宕了的話，需要在剩下的兩個中選舉出Master繼續工作。
所以這三個Job需要互相協調：
-
使用共享數據庫表。我們知道數據庫主鍵不能衝突，可以讓三個Job向表中插入同樣的數據，誰成功誰就是Master。缺點是如果搶到Master的Job掛了，則記錄永遠存在，其他的Job無法插入數據。所以必須加上定期更新的機制。
-
讓Job在啓動後，去註冊中心註冊，也就是創建一個樹節點，誰成功誰是Master（註冊中心必須保證只能創建成功一次）。
這樣，如果節點刪除了，就開始新一輪爭搶。
4 Zookeeper作用與特性
4.1 作用
- master節點選舉, 主節點down掉後, 從節點就會接手工作, 並且保證這個節點是唯一的,這也就是所謂首腦模式,從而保證我們集羣是高可用的
- 統一配置文件管理, 即只需要部署一臺服務器, 則可以把相同的配置文件同步更新到其他所有服務器, 此操作在雲計算中用的特別多(例如修改了redis統一配置)
- 數據發佈與訂閱, 類似消息隊列MQ
- 分佈式鎖,分佈式環境中不同進程之間爭奪資源,類似於多進程中的鎖
- 集羣管理, 保證集羣中數據的強一致性
4.2 特性
- 一致性: 數據一致性, 數據按照順序分批入庫
- 原子性: 事務要麼成功要麼失敗
- 單一視圖: 客戶端連接集羣中的任意zk節點, 數據都是一致的
- 可靠性:每次對zk的操作狀態都會保存在服務端
- 實時性: 客戶端可以讀取到zk服務端的最新數據
待更..............
參考：