zookeeper概要、協議、應用場景

1. zookeeper產生背景：

? zookeeper是為了解決分布式系統一致性的問題產生的，其使用了ZAB協議(Zookeeper Atomic Broadcast zookeeper原理廣播協議)

專案從單體到分布式轉變之后，將會產生多個節點之間協同的問題，

1. 每天的定時任務由誰哪個節點來執行？
2. RPC呼叫時的服務發現?
3. 如何保證并發請求的冪等
4. …

這些問題可以統一歸納為多節點協調問題，如果靠節點自身進行協調這是非常不可靠的，性能上也不可取，必須由一個獨立的服務做協調作業，它必須可靠，而且保證性能，

分布式系統中的行程通信有兩種選擇：直接通過?絡進?資訊交換， 或讀寫某些共享存盤，

ZooKeeper使?共享存盤模型來實作應?間的協作和 同步原語，對于共享存盤本?，又需要在行程和存盤間進??絡通信，我們強調?絡通信的重要性，因為它是分布式系統中并發設計的基礎，

ZAB協議原理

分布式系統一致性演算法應用于系統軟體實作集群保持每個節點資料的同步性，保持我們的集群中每個節點的資料的一致性問題，

常用分布式系統一致性演算法：raf協議、zab協議、paxos協議，

zookeeper使用主備模型架構來保持集群中各個節點的資料一致性，使用一個單節點(leader節點)來接受處理客戶端的事務請求，并通過zab協議將資料變更以事務proposal的形式廣播給其他子節點（follower）

zookeeper有兩種運行狀態：1. 崩潰恢復 2. 訊息廣播

崩潰恢復：

? 服務啟動或者宕機重啟會進行選舉出新的leader同時leader和過半節點完成資料狀態同步后會進行正常的訊息廣播模式，

1、選擇保證資料一致

• ZAB協議需要確保事務leade處理成功,則在所有機器都應該被處理成功(這里處理成功是指提出事務和commit都完成)

• ZAB協議需要確保丟棄只在leader節點提出的事務

  這兩種情況可以使用ZXID實作 只要選舉出來的具有最高的ZXID編號的，可以保證選舉出來的leader一定具有所有已經提交的提案，同時也省去了leader去提交和丟棄提案的步驟，

2、資料同步

選舉完成的leader會將自己提交的提案中沒有被其他follower節點同步的提案以訊息的形式發送到其對應的佇列中，follower消費訊息進行資料同步 并進行ack確認接收commit提交，類似于正常的訊息廣播

訊息廣播模式：

leader節點將客戶事務提交轉換成一個Proposal并分發給集群所有fllower節點，超過半數的節點提供給leader正確反饋，leader節點會再次向所有Follower服務器分發commit訊息將前一個proposal進行提交，類似于現代民主投票

資料（廣播協議）之間同步采用: 2pc兩階段提交協議 同時使用FIFO順序的TCP協議保證訊息發送和接受的順序性

2. zookeeper概要

ZooKeeper是用于分布式應用程式的協調服務，它公開了一組簡單的API，分布式應用程式可以基于這些API用于同步，節點狀態、配置等資訊、服務注冊等資訊，其由JAVA撰寫，支持JAVA 和C兩種語言的客戶端，ZooKeeper顧名思意：動物園管理員

2.1設計模式來理解

ZK是一個基于觀察者模式設計的分布式服務管理框架，

它負責存盤和管理大家都關心的資料(集群下資料會保持一致性)，

然后接受觀察者的注冊(watch機制)，

一旦這些資料的狀態發生變化，Zookeeper就將負責通知watch已經在Zookeeper上注冊的那些觀察者做出相應的反應，從而實作集群中類似Master/Slave管理模式

2.2 一句話

zookeeper=類似unix檔案系統+通知機制+Znode節點

作用：服務注冊+分布式系統的一致性通知協調

3. 資料結構 - znode 節點

zookeeper 中資料基本單元叫節點，節點之下可包含子節點，最后以樹級方式呈現，每個節點擁有唯一的路徑path，客戶端基于PATH上傳節點資料，zookeeper 收到后會實時通知對該路徑進行監聽的客戶端，

（ZooKeeper資料模型的結構與Unix檔案系統很類似，整體上可以看作是一棵樹，每個節點稱做一個ZNode，每一個ZNode默認能夠存盤1MB的資料，每個ZNode都可以通過其路徑唯一標識，）

4. 特點

1. Zookeeper：一個領導者（leader），多個跟隨者（follower）組成的集群，
2. Leader負責進行投票的發起和決議，更新系統狀態(寫資料)
3. Follower用于接收客戶請求并向客戶端回傳結果（讀資料），在選舉Leader程序中參與投票
4. 集群中只要有半數以上節點存活，Zookeeper集群就能正常服務，
5. 全域資料一致：每個server保存一份相同的資料副本，client無論連接到哪個server，資料都是一致的，
6. 更新請求順序進行，來自同一個client的更新請求按其發送順序依次執行，
7. 資料更新原子性，一次資料更新要么成功，要么失敗，
8. 實時性，在一定時間范圍內，client能讀到最新資料，

5. 應用場景

提供的服務包括：統一命名服務dubbo注冊中心、統一配置管理(zk實作的配置中心)、統一集群管理、服務器節點動態上下線、軟負載均衡等，

5.1 統一命名服務（Name Service如Dubbo服務注冊中心)

**命名服務是將一個名稱映射到與該名稱有關聯的一些資訊的服務，**電話目錄是將人的名字映射到其電話號碼的一個名稱服務，同樣，DNS 服務也是一個名稱服務，它將一個域名映射到一個 IP 地址，在分布式系統中，您可能想跟蹤哪些服務器或服務在運行，并通過名稱查看其狀態，ZooKeeper 暴露了一個簡單的介面來完成此作業，也可以將名稱服務擴展到組成員服務，這樣就可以獲得與正在查找其名稱的物體有關聯的組的資訊，

Dubbo是一個分布式服務框架，致力于提供高性能和透明化的RPC遠程服務呼叫方案，是阿里巴巴SOA服務化治理方案的核心框架，每天為2,000+個服務提供3,000,000,000+次訪問量支持，并被廣泛應用于阿里巴巴集團的各成員站點，

在Dubbo實作中：服務提供者在啟動的時候，向ZK上的指定節點/dubbo/ s e r v i c e N a m e / p r o v i d e r s 目 錄 下 寫 入 自 己 的 U R L 地 址 ， 這 個 操 作 就 完 成 了 服 務 的 發 布 ， 服 務 消 費 者 啟 動 的 時 候 ， 訂 閱 / d u b b o / {serviceName}/providers目錄下寫入自己的URL地址，這個操作就完成了服務的發布，服務消費者啟動的時候，訂閱/dubbo/ serviceName/providers目錄下寫入自己的URL地址，這個操作就完成了服務的發布，服務消費者啟動的時候，訂閱/dubbo/{serviceName}/providers目錄下的提供者URL地址， 并向/dubbo/${serviceName} /consumers目錄下寫入自己的URL地址，

在分布式環境下，經常需要對應用/服務進行統一命名，便于識別不同服務，

1. 類似于域名與ip之間對應關系，ip不容易記住，而域名容易記住，
2. 通過名稱來獲取資源或服務的地址，提供者等資訊，

一句話總結：path就是命名服務，客戶端能夠根據指定節點的名字來獲取資源或者服務地址，然后進行下一步操作

5.2 統一配置管理（Configuration Management如淘寶開源配置管理框架Diamond）

在大型的分布式系統中，為了服務海量的請求，同一個應用常常需要多個實體，如果存在配置更新的需求，常常需要逐臺更新，給運維增加了很大的負擔同時帶來一定的風險(配置會存在不一致的視窗期，或者個別節點忘記更新)，zookeeper可以用來做集中的配置管理，存盤在zookeeper集群中的配置，如果發生變更會主動推送到連接配置中心的應用節點，實作一處更新處處更新的效果，

現在把這些配置全部放到zookeeper上去，保存在 Zookeeper 的某個目錄節點中，然后所有相關應用程式對這個目錄節點進行監聽，一旦配置資訊發生變化，每個應用程式就會收到 Zookeeper 的通知，然后從 Zookeeper 獲取新的配置資訊應用到系統中就好，

分布式環境下，組態檔管理和同步是一個常見問題，

1. 一個集群中，所有節點的配置資訊是一致的，比如 Hadoop 集群，
2. 對組態檔修改后，希望能夠快速同步到各個節點上，

配置管理可交由ZooKeeper實作，

1. 可將配置資訊寫入ZooKeeper上的一個Znode，
2. 各個節點監聽這個Znode，
3. 一旦Znode中的資料被修改，ZooKeeper將通知各個節點，

5.3 統一集群管理

分布式環境中，實時掌握每個節點的狀態是必要的，

1. 可根據節點實時狀態做出一些調整，
2. 可交由ZooKeeper實作，
   1. 可將節點資訊寫入ZooKeeper上的一個Znode，
   2. 監聽這個Znode可獲取它的實時狀態變化，
3. 典型應用
   1. HBase中Master狀態監控與選舉，

5.4 服務器動態上下線

利用zk臨時節點實作監聽服務器上下線，

5.5 軟負載均衡

5.6 分布式訊息同步和協調機制

5.7 總結

Zoopkeeper提供了一套很好的分布式集群管理的機制，就是它這種基于層次型的目錄樹的資料結構，

并對樹中的節點進行有效管理，從而可以設計出多種多樣的分布式的資料管理模型，作為分布式系統的溝通調度橋梁