在學(xué)習(xí)一樣技術(shù)之前，咱們需要先想一下，為什么需要學(xué)這一門技術(shù)雹顺？
許多分布式系統(tǒng)都是基于ZK作為底層核心組件對外提供服務(wù)，比如Kafka中廊遍，將Broker注冊到ZK中嬉愧，此時ZK充當(dāng)著多重角色，比如注冊中心喉前、選舉等英染；再比如說，我公司目前很多項目都是Dubbo被饿，都是需要基于ZK實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)和注冊四康。
另外，ZK內(nèi)其實(shí)也有很多優(yōu)秀的算法和設(shè)計思想狭握，熟悉ZK源碼闪金，也可以提升自己的“內(nèi)功”。
如何快速入門Zookeeper呢论颅？最簡單的方式就是直接看 Zookeeper官網(wǎng) 啦哎垦！建議讀者多參考官方文檔和博客內(nèi)容一起食用，效果更佳噢～
Zookeeper是什么恃疯？
字面上意思可以認(rèn)為是“動物園管理員”漏设！為什么會有這一個名字呢？先來看下 Hadoop 的生態(tài)系統(tǒng)圖
Zookeeper的 Logo 看起來就像個“鏟屎官”今妄，服務(wù)動物園內(nèi)的動物們郑口。
“A Distributed Coordination Service for Distributed Applications”鸳碧，這是摘取官方的解釋，我們可以得知Zookeeper 是一個為分布式框架提供協(xié)調(diào)服務(wù)的東東犬性。
舉些例子瞻离，有哪些分布式框架使用Zookeeper：
Kafka（最新版本中其實(shí)去掉ZK作為注冊中心）
Hbase
Dubbo
HDFS
等等
Zookeeper的常用使用場景有哪些？
分布式鎖
注冊中心
Leader選舉
ZK的作用不止上面幾個乒裆，其實(shí)還可以做到負(fù)載均衡套利、統(tǒng)一配置、分布式隊列等鹤耍，但使用場景相對少肉迫，企業(yè)級系統(tǒng)中，會使用其他更加專業(yè)的框架組件稿黄。
分布式鎖昂拂、注冊中心、Leader選舉將會是ZK系列中抛猖，重點(diǎn)分享的內(nèi)容格侯，敬請期待哈~
重點(diǎn)概念
在ZK中，需要先了解一些專業(yè)名詞的概念财著，但不會一下子都列出來联四，當(dāng)之后遇到的時候，再重點(diǎn)分析...
1. ZK角色
在ZK集群中撑教，會分為Leader朝墩、Follower和Observer角色。
Leader作為集群的大佬伟姐，承擔(dān)寫請求和部分讀請求收苏；Follower作為Leader的小弟，將會承擔(dān)部分讀請求愤兵，當(dāng)接收到寫請求的時候會轉(zhuǎn)發(fā)給Leader鹿霸，由Leader處理寫請求；Observer就有點(diǎn)特殊秆乳，Observer節(jié)點(diǎn)不參與選舉和消息過半機(jī)制懦鼠，這個不清楚的讀者可以暫時有個記憶就行，之后遇到會重點(diǎn)說明屹堰。
2. 節(jié)點(diǎn)類型
持久節(jié)點(diǎn)(PERSISTENT)
持久順序節(jié)點(diǎn)(PERSISTENT_SEQUENTIAL)
臨時節(jié)點(diǎn)(EPHEMERAL)
順序臨時節(jié)點(diǎn)(EPHEMERAL_SEQUENTIAL)
實(shí)際上肛冶，節(jié)點(diǎn)只分為持久節(jié)點(diǎn)和臨時節(jié)點(diǎn)，但有些場景需要保證順序扯键，所以就會在持久或臨時節(jié)點(diǎn)的基礎(chǔ)上睦袖，添加序號（遞增的方式），形成持久順序節(jié)點(diǎn)和臨時順序節(jié)點(diǎn)荣刑。</br> 那么什么是持久節(jié)點(diǎn)馅笙，什么是臨時節(jié)點(diǎn)呢伦乔？最直觀的一個現(xiàn)象就是，每個ZK客戶端連接ZK集群后延蟹，都會產(chǎn)生一個節(jié)點(diǎn)，如果ZK客戶端下線后叶堆，節(jié)點(diǎn)還存在的就是持久節(jié)點(diǎn)阱飘，若ZK客戶端下線后節(jié)點(diǎn)也隨著消失，那么該節(jié)點(diǎn)就是臨時節(jié)點(diǎn)虱颗。
3. 監(jiān)聽回調(diào)
在ZK客戶端啟動前沥匈，可以自定義監(jiān)聽回調(diào)函數(shù)，這個有什么作用呢忘渔？客戶端啟動后會將監(jiān)聽事件發(fā)送給Zookeeper集群高帖，Zookeeper集群中有一個用于記錄監(jiān)聽事件的列表，當(dāng)客戶端監(jiān)聽的目錄節(jié)點(diǎn)發(fā)生變化畦粮，如節(jié)點(diǎn)數(shù)據(jù)變更散址、節(jié)點(diǎn)增刪等，就會通過ZK集群的監(jiān)聽列表宣赔，找到對應(yīng)的客戶端回調(diào)監(jiān)聽函數(shù)预麸，那么客戶端這邊就可以根據(jù)業(yè)務(wù)場景，做出相應(yīng)的動作儒将。
4. ZAB協(xié)議
ZAB協(xié)議的全稱是：ZooKeeper Atomic Broadcast吏祸。ZAB是Zookeeper保證數(shù)據(jù)一致性的核心算法。借鑒了Paxos算法的思想钩蚊，特地為Zookeeper設(shè)計的支持崩潰恢復(fù)的原子廣播協(xié)議贡翘。其包括兩種基本模式：消息廣播和崩潰恢復(fù)
消息廣播指的是，集群中只有一個Leader處理寫請求砰逻，并將寫請求的事件廣播給所有Follower鸣驱，且能夠保證數(shù)據(jù)不丟失。（也就是說蝠咆，消息的寫入是原子性的丐巫，因?yàn)橹荒苡衛(wèi)eader寫入）
崩潰恢復(fù)指的是，當(dāng)ZK集群剛啟動還沒選舉出Leader或Leader因故障勺美、重啟递胧、網(wǎng)絡(luò)等原因的時候，ZAB協(xié)議會進(jìn)入崩潰恢復(fù)模式赡茸，其目的就是為了選舉新的Leader缎脾，且保證新Leader的數(shù)據(jù)是最新的，這樣就能夠避免因?yàn)長eader故障而導(dǎo)致單點(diǎn)丟失消息的情況占卧，至于ZAB具體的原理遗菠，各位可以先看下以下參考文章联喘，后續(xù)有機(jī)會我再專門寫一篇關(guān)于 ZAB 協(xié)議的文章~
Zookeeper架構(gòu)特點(diǎn)
數(shù)據(jù)模型
ZK內(nèi)的數(shù)據(jù)模型結(jié)構(gòu)和Unix文件系統(tǒng)非常相似，是一個有層級關(guān)系的樹形數(shù)據(jù)結(jié)構(gòu)辙纬。在ZK內(nèi)豁遭，樹形的數(shù)據(jù)結(jié)構(gòu)使用稱為ZNode節(jié)點(diǎn)保存數(shù)據(jù)，ZNode是ZK中數(shù)據(jù)結(jié)構(gòu)最小單元贺拣，不僅能夠保存數(shù)據(jù)蓖谢，還能掛載子節(jié)點(diǎn)，形成一個有層次關(guān)系的樹譬涡。
值得注意的是闪幽，ZNode的創(chuàng)建是純內(nèi)存操作的，所以速度很快涡匀，然后在ZK內(nèi)部會定期將ZNode的數(shù)據(jù)持久化到磁盤上盯腌。
集群部署
眾所周知，在實(shí)際的企業(yè)應(yīng)用陨瘩，面對高并發(fā)的場景下腕够，肯定是不能單節(jié)點(diǎn)部署，而是通過集群部署保證高并發(fā)舌劳、高性能燕少、高可用（簡稱三高）。
高性能：由于ZNode節(jié)點(diǎn)是純內(nèi)存操作蒿囤，只要ZK部署在高配置的服務(wù)器中客们，三臺ZK服務(wù)器抗住每秒幾萬的請求都是沒問題的。 高可用：只要部署奇數(shù)的服務(wù)器集群（比如3臺材诽、5臺底挫、11臺機(jī)器），只要不超過一半的服務(wù)器宕機(jī)脸侥，都能保證ZK集群可用建邓。 高并發(fā)：因?yàn)閆Node是純內(nèi)存操作，所以在寫數(shù)據(jù)的時候睁枕，速度是很快官边；而ZK集群中Leader和Follower節(jié)點(diǎn)都能處理讀請求，所以ZK集群高并發(fā)能力是很強(qiáng)的外遇。
順序一致性
基于ZAB協(xié)議注簿，寫請求統(tǒng)一由Leader服務(wù)器處理，然后由Leader將寫數(shù)據(jù)的請求廣播給其他Follower跳仿。
但會不會由于種種原因诡渴，如網(wǎng)絡(luò)波動、Leader腦裂菲语、Follower宕機(jī)等妄辩，導(dǎo)致消息不一致惑灵？
實(shí)際上，在ZK中采用2PC兩階段提交的思想眼耀，結(jié)合ZAB消息廣播保證數(shù)據(jù)一致性英支。值得注意的是，Zookeeper只能保證最終一致性哮伟，并不能保證強(qiáng)一致性
那么具體是怎么保證數(shù)據(jù)最終一致性的呢干花？感興趣的讀者可以看下我另外一篇拙作【TODO...】
參考資料：
《從Paxos到Zookeeper分布式一致性原理與實(shí)踐》
如果覺得文章不錯的話，麻煩點(diǎn)個贊哈澈吨，你的鼓勵就是我的動力把敢！對于文章有哪里不清楚或者有誤的地方寄摆，歡迎在評論區(qū)留言~
