來源:http://ningg.top/zookeeper-positioning
# 目標
ZooKeeper 很流行,有個基本的疑問:
ZooKeeper 是用來做什麼的?
之前沒有ZK,爲什麼會誕生 ZK?
OK,解答一下上面的疑問:(下面是憑直覺說的)
ZooKeeper 是用於簡化分佈式應用開發的,對開發者屏蔽一些分佈式應用開發過程中的底層細節
ZooKeeper 對外暴露簡單的 API,用於支持分佈式應用開發
ZooKeeper 在提供上述功能的同時,其還是一個 高性能、高可用、高可靠的分佈式集羣
上面說這麼多,總結一下,ZK 能解決分佈式應用開發的問題,ZK 能很好的解決問題。到這一步,疑問就更多了:
分佈式應用開發,有哪些常見問題?ZK 是如何屏蔽這些底層細節的?
ZooKeeper 對外暴露了那些 API?這些 API 如何支持分佈式應用開發的?這些 API 還能簡化嗎?API 的語義性怎麼樣?
ZooKeeper 自身是一個高性能、高可用、高可靠的分佈式集羣,那有個簡單的問題:
高性能是指什麼?ZooKeeper 爲了達到高性能,做了哪些工作?
高可用同上
高可靠同上
Note:本篇 wiki 就是爲了解決上述第一個疑問的
# 爲什麼有 ZooKeeper
一個應用程序,涉及多個進程協作時,業務邏輯代碼中混雜有大量複雜的進程協作邏輯。
上述多進程協作邏輯,有 2 個特點:
處理複雜
處理邏輯可重用
因此,考慮將多進程協作的共性問題拎出,作爲基礎設施,讓 RD 更加專注業務邏輯開發,即:
ZooKeeper 就是上述多進程協作基礎服務的一種。
# ZooKeeper 的特點
ZooKeeper 有幾個簡單特點:
ZooKeeper 的 API:從 文件系統 API 得到的啓發,提供簡單的 API
ZooKeeper 運行在專用服務器上,跟業務邏輯分離,保證了高容錯性和可擴展性
ZooKeeper 是存儲設施,但特別注意
ZK上存儲的數據聚焦爲:協作數據(元數據),而不是應用數據,應用數據有自己的存儲方案,例如 HDFS 等
ZK 本質上,可以看作一種特殊的 FS
特別說明:
應用數據和元數據,由於使用場景不同,對一致性和持久性的要求有差異, 因此,架構設計、數據治理過程中,應將 2 類數據獨立看待、獨立存儲。
# ZooKeeper 的使命
ZK 要解決的核心問題:
ZK 目標:簡化分佈式應用開發中,多進程協作問題。爲分佈式應用,提供高效、可靠的分佈式協調服務(基礎服務),例如:
統一的命名服務
分佈式鎖
進程崩潰檢測
Leader 選舉
配置管理:配置變更時,及時下發到各個 Client。
一個簡單的問題:多進程的協作是什麼?尼瑪呀,有完沒完,啥問題你都有,面對這個掉咋天的腦殼,還是回答一下。
多進程協作,整體分爲 2 類:
協作:多進程需要一同處理某些事情,一些進程採取行動是的其他進程能夠正常工作,例如:主從結構,M 向 S 分配任務,S 纔會執行,否則 S 就保持空閒狀態
競爭:兩個進程不能同時工作,一個進程必須等待另個進程執行完畢,例如:主從結構,M 節點失效後,很多 S 都想成爲 M,這時,就需要互斥鎖,只有第一個獲得鎖的 S 成爲 M
特別說明:
不跨網絡協作:多進程,可以在同一臺物理主機上,同步原語很方便(比如?管道、共享內存、消息隊列、信號量)
跨網絡協作:多進程,分佈在不同的物理主機上,ZK 關注這一類
跨網絡多進程協作,進程通信,基本思路有 2 個:
消息機制:通過網絡,直接信息交換,多消息傳遞算法,實現同步原語
共享存儲:利用外部共享存儲,實現多進程協作,要求共享存儲提供有序訪問,ZK 採用這種方式
真實系統中,跨網絡通信,有幾個共性問題:
消息延遲:由於網絡原因,後發送先到達
處理器性能:由於系統調度原因,消息到達後,延遲處理
時鐘偏移:不同物理主機,時鐘發生偏移
ZK 精心設計用於屏蔽上述 3 個共性問題,使得這些問題在應用服務層面完全透明化。
# ZooKeeper 特性
ZooKeeper 解決的本質問題
分佈式系統的一致性問題:
消息傳遞:延遲性,先發送的消息,不一定先到達;
消息傳遞:丟失性,發送的消息,可能丟失;
節點崩潰:分佈式系統內,任何一個節點都可能崩潰;
在這種情況下,如何保證數據的一致性?
提案投票:基於投票策略,2PC
選舉投票:基於投票策略,投出優先級最高的節點(包含最新數據的節點)
Paxos 目標:解決分佈式一致性問題,提高分佈式系統容錯性的一致性算法。
Paxos 本質:基於消息傳遞的高度容錯的一致性算法
# ZooKeeper 定位
ZooKeeper 是:
分佈式協調服務
高效、可靠
方便應用程序,聚焦業務邏輯開發,而不需要過多關注分佈式進程間協作細節
ZooKeeper 不直接暴露原語,而是,暴露一部分調用方法組成的 API,類似文件系統的 API,支持應用程序實現自己的原語。
# ZooKeeper 特性
ZooKeeper 可以保證如下分佈式一致性特性:
順序一致性:同一個 Client 發起的事務請求,嚴格按照發起順序執行
原子性:事務請求,要麼應用到所有節點,要麼一個節點都沒有應用
單一視圖:Client 無論連接到哪個節點,看到的服務端數據都是一致的(Note:不準確,其實是最終一致性)
可靠性:事務一旦執行成功,狀態永久保留
實時性:事務一旦執行成功,Client 並不能立即看到最新數據,但 ZooKeeper 保證最終一致性
# ZooKeeper 設計目標
ZooKeeper 致力於提供高性能、高可用、順序一致性的分佈式協調服務,保證數據最終一致性。
目標一:高性能(簡單的數據模型)
採用樹形結構組織數據節點;
全量數據節點,都存儲在內存中;
Follower 和 Observer 直接處理非事務請求;
目標二:高可用(構建集羣)
半數以上機器存活,服務就能正常運行
自動進行 Leader 選舉
目標三:順序一致性(事務操作的順序)
每個事務請求,都會轉發給 Leader 處理
每個事務,會分配全局唯一的遞增id(zxid,64位:epoch + 自增 id)
目標四:最終一致性
通過提議投票方式,保證事務提交的可靠性
提議投票方式,只能保證 Client 收到事務提交成功後,半數以上節點能夠看到最新數據
# ZooKeeper 出現之前
ZK 出現之前,分佈式系統常用兩種方式,實現多進程協作:
分佈式鎖管理器
分佈式數據庫
ZK 更專注於進程協作,而不提供任何鎖接口和通用的存儲數據接口。(疑問:ZK 也可以提供啊,我們不使用就行了)
應用服務器,常見的 2 種需求:
Master-Slave Leader 選舉:要求提供Master節點選舉功能
進程響應跟蹤 崩潰檢測:要求提供進程存活狀態的跟蹤
分佈式鎖:互斥排它鎖
ZK 爲上述 2 種策略提供了基礎 API。
ZooKeeper 不適用的場景:
海量數據存儲:ZK 本質是特殊的 FS,但 ZK 用於存儲元數據,需要單獨存儲應用數據。
# 術語介紹
# 參考資料
[1]ZooKeeper-Distributed Process Coordination: http://shop.oreilly.com/product/0636920028901.do
[2]從Paxos到Zookeeper分佈式一致性原理與實踐: https://book.douban.com/subject/26292004
推薦閱讀
面試題:InnoDB 中一棵 B+ 樹能存多少行數據?【面試不翻車,翻車就跑路】
我畫了35張圖就是爲了讓你深入 AQS
Map 集合怎麼也有這麼多坑?一不小心又踩了好幾個!