ZooKeeper(一)
ZooKeeper 是什麼？
ZooKeeper 是一個開源的分佈式協調服務系統。用於分佈式項目中，用來完成統一命名服務、狀態同步服務、集羣管理、分佈式應用配置項的管理等工作。
它是一個爲分佈式應用提供一致性服務的軟件，分佈式應用程序可以基於 Zookeeper 實現諸如數據發佈/訂閱、負載均衡、命名服務、分佈式協調/通知、集羣管理、Master 選舉、分佈式鎖和分佈式隊列等功能。
ZooKeeper 的目標就是封裝好複雜易出錯的關鍵服務，將簡單易用的接口和性能高效、功能穩定的系統提供給用戶
Zookeeper 保證瞭如下分佈式一致性特性：
（1）順序一致性
（2）原子性
（3）單一視圖
（4）可靠性
（5）實時性（最終一致性）
客戶端的讀請求可以被集羣中的任意一臺機器處理，如果讀請求在節點上註冊了監聽器，這個監聽器也是由所連接的 zookeeper 機器來處理。
對於寫請求，這些請求會同時發給其他 zookeeper 機器並且達成一致後，請求才會返回成功。因此，隨着 zookeeper 的集羣機器增多，讀請求的吞吐會提高但是寫請求的吞吐會下降。
有序性是 zookeeper 中非常重要的一個特性，所有的更新都是全局有序的，每個更新都有一個唯一的時間戳，這個時間戳稱爲 zxid（Zookeeper Transaction Id）。而讀請求只會相對於更新有序，也就是讀請求的返回結果中會帶有這個zookeeper 最新的 zxid。
ZooKeeper 提供了什麼？
文件系統
通知機制
Zookeeper 文件系統
Zookeeper 提供一個多層級的節點命名空間（節點稱爲 znode）。與文件系統不同的是，這些節點都可以設置關聯的數據，而文件系統中只有文件節點可以存放數據而目錄節點不行。
Zookeeper 爲了保證高吞吐和低延遲，在內存中維護了這個樹狀的目錄結構，這種特性使得 Zookeeper 不能用於存放大量的數據，每個節點的存放數據上限爲1M。
Zookeeper 怎麼保證主從節點的狀態同步？
Zookeeper 的核心是原子廣播機制，這個機制保證了各個 server 之間的同步。實現這個機制的協議叫做 Zab 協議。Zab 協議有兩種模式，它們分別是恢復模式和廣播模式。
恢復模式
當服務啓動或者在領導者崩潰後，Zab就進入了恢復模式，當領導者被選舉出來，且大多數 server 完成了和 leader 的狀態同步以後，恢復模式就結束了。狀態同步保證了 leader 和 server 具有相同的系統狀態。
廣播模式
一旦 leader 已經和多數的 follower 進行了狀態同步後，它就可以開始廣播消息了，即進入廣播狀態。這時候當一個 server 加入 ZooKeeper 服務中，它會在恢復模式下啓動，發現 leader，並和 leader 進行狀態同步。待到同步結束，它也參與消息廣播。ZooKeeper 服務一直維持在 Broadcast 狀態，直到 leader 崩潰了或者 leader 失去了大部分的 followers 支持。
服務器角色
Leader
（1）事務請求的唯一調度和處理者，保證集羣事務處理的順序性
（2）集羣內部各服務的調度者
Follower
（1）處理客戶端的非事務請求，轉發事務請求給 Leader 服務器
（2）參與事務請求 Proposal 的投票
（3）參與 Leader 選舉投票
Observer
（1）3.0 版本以後引入的一個服務器角色，在不影響集羣事務處理能力的基礎上提升集羣的非事務處理能力
（2）處理客戶端的非事務請求，轉發事務請求給 Leader 服務器
（3）不參與任何形式的投票
Zookeeper 下 Server 工作狀態
服務器具有四種狀態，分別是 LOOKING、FOLLOWING、LEADING、OBSERVING。
（1）LOOKING：尋 找 Leader 狀態。當服務器處於該狀態時，它會認爲當前集羣中沒有 Leader，因此需要進入 Leader 選舉狀態。
（2）FOLLOWING：跟隨者狀態。表明當前服務器角色是 Follower。
（3）LEADING：領導者狀態。表明當前服務器角色是 Leader。
（4）OBSERVING：觀察者狀態。表明當前服務器角色是 Observer。
zookeeper 是如何保證事務的順序一致性的？
zookeeper 採用了全局遞增的事務 Id 來標識，所有的 proposal（提議）都在被提出的時候加上了 zxid，zxid 實際上是一個 64 位的數字，高 32 位是 epoch（ 時期; 紀元; 世; 新時代）用來標識 leader 週期，如果有新的 leader 產生出來，epoch會自增，低 32 位用來遞增計數。當新產生 proposal 的時候，會依據數據庫的兩階段過程，首先會向其他的 server 發出事務執行請求，如果超過半數的機器都能執行並且能夠成功，那麼就會開始執行
分佈式集羣中爲什麼會有 Master主節點？
在分佈式環境中，有些業務邏輯只需要集羣中的某一臺機器進行執行，其他的機器可以共享這個結果，這樣可以大大減少重複計算，提高性能，於是就需要進行 leader 選舉。
zk 節點宕機如何處理？
Zookeeper 本身也是集羣，推薦配置不少於 3 個服務器。Zookeeper 自身也要保證當一個節點宕機時，其他節點會繼續提供服務。
如果是一個 Follower 宕機，還有 2 臺服務器提供訪問，因爲 Zookeeper 上的數據是有多個副本的，數據並不會丟失；
如果是一個 Leader 宕機，Zookeeper 會選舉出新的 Leader。
ZK 集羣的機制是隻要超過半數的節點正常，集羣就能正常提供服務。只有在 ZK節點掛得太多，只剩一半或不到一半節點能工作，集羣才失效。
zookeeper 負載均衡和 nginx 負載均衡區別
zk 的負載均衡是可以調控，nginx 只是能調權重，其他需要可控的都需要自己寫插件；但是 nginx 的吞吐量比 zk 大很多，應該說按業務選擇用哪種方式。
Zookeeper 有哪幾種幾種部署模式？
Zookeeper 有三種部署模式：
單機部署：一臺集羣上運行；
集羣部署：多臺集羣運行；
僞集羣部署：一臺集羣啓動多個 Zookeeper 實例運行。
Zookeeper 的 java 客戶端都有哪些？
java 客戶端：zk 自帶的 zkclient 及 Apache 開源的 Curator。
zookeeper 常用的命令
常用命令：ls get set create delete 等。
Zookeeper 都有哪些功能？
1.集羣管理：監控節點存活狀態、運行請求等；
2.主節點選舉：主節點掛掉了之後可以從備用的節點開始新一輪選主，主節點選舉說的就是這個選舉的過程，使用 Zookeeper 可以協助完成這個過程；
3分佈式鎖：Zookeeper 提供兩種鎖：獨佔鎖、共享鎖。獨佔鎖即一次只能有一個線程使用資源，共享鎖是讀鎖共享，讀寫互斥，即可以有多線線程同時讀同一個資源，如果要使用寫鎖也只能有一個線程使用。Zookeeper 可以對分佈式鎖進行控制。
4命名服務：在分佈式系統中，通過使用命名服務，客戶端應用能夠根據指定名字來獲取資源或服務的地址，提供者等信息。
Zookeeper 的通知機制？
client 端會對某個 znode 建立一個 watcher 事件，當該 znode 發生變化時，這些 client 會收到 zk 的通知，然後 client 可以根據 znode 變化來做出業務上的改變等。