前言
相信大家對(duì) ZooKeeper 應(yīng)該不算陌生荐开。但是你真的了解 ZooKeeper 是個(gè)什么東西嗎沛慢？如果別人/面試官讓你給他講講 ?ZooKeeper 是個(gè)什么東西楞泼，你能回答到什么地步呢甸各？
我本人曾經(jīng)使用過 ZooKeeper 作為 Dubbo 的注冊(cè)中心忽冻，另外在搭建 solr 集群的時(shí)候，我使用到了 ?ZooKeeper 作為 solr 集群的管理工具雌团。前幾天燃领，總結(jié)項(xiàng)目經(jīng)驗(yàn)的時(shí)候，我突然問自己 ZooKeeper 到底是個(gè)什么東西锦援？想了半天猛蔽，腦海中只是簡單的能浮現(xiàn)出幾句話：“①Zookeeper 可以被用作注冊(cè)中心。 ②Zookeeper 是 Hadoop 生態(tài)系統(tǒng)的一員雨涛；③構(gòu)建 Zookeeper 集群的時(shí)候枢舶，使用的服務(wù)器最好是奇數(shù)臺(tái)√婢茫” 可見凉泄，我對(duì)于 Zookeeper 的理解僅僅是停留在了表面。
所以蚯根，通過本文后众，希望帶大家稍微詳細(xì)的了解一下 ZooKeeper 。如果沒有學(xué)過 ZooKeeper 颅拦，那么本文將會(huì)是你進(jìn)入 ZooKeeper 大門的墊腳磚蒂誉。如果你已經(jīng)接觸過 ZooKeeper ，那么本文將帶你回顧一下 ZooKeeper 的一些基礎(chǔ)概念距帅。
最后右锨，本文只涉及 ZooKeeper 的一些概念，并不涉及 ZooKeeper 的使用以及 ZooKeeper 集群的搭建碌秸。網(wǎng)上有介紹 ZooKeeper 的使用以及搭建 ZooKeeper 集群的文章绍移，大家有需要可以自行查閱。
下面這段內(nèi)容摘自《從Paxos到Zookeeper 》第四章第一節(jié)的某段內(nèi)容讥电，推薦大家閱讀以下：
Zookeeper最早起源于雅虎研究院的一個(gè)研究小組蹂窖。在當(dāng)時(shí)，研究人員發(fā)現(xiàn)恩敌，在雅虎內(nèi)部很多大型系統(tǒng)基本都需要依賴一個(gè)類似的系統(tǒng)來進(jìn)行分布式協(xié)調(diào)瞬测，但是這些系統(tǒng)往往都存在分布式單點(diǎn)問題。所以纠炮，雅虎的開發(fā)人員就試圖開發(fā)一個(gè)通用的無單點(diǎn)問題的分布式協(xié)調(diào)框架月趟，以便讓開發(fā)人員將精力集中在處理業(yè)務(wù)邏輯上。
關(guān)于“ZooKeeper”這個(gè)項(xiàng)目的名字恢口，其實(shí)也有一段趣聞狮斗。在立項(xiàng)初期，考慮到之前內(nèi)部很多項(xiàng)目都是使用動(dòng)物的名字來命名的（例如著名的Pig項(xiàng)目),雅虎的工程師希望給這個(gè)項(xiàng)目也取一個(gè)動(dòng)物的名字弧蝇。時(shí)任研究院的首席科學(xué)家RaghuRamakrishnan開玩笑地說：“在這樣下去，我們這兒就變成動(dòng)物園了！”此話一出看疗，大家紛紛表示就叫動(dòng)物園管理員吧一一一因?yàn)楦鱾€(gè)以動(dòng)物命名的分布式組件放在一起沙峻，雅虎的整個(gè)分布式系統(tǒng)看上去就像一個(gè)大型的動(dòng)物園了，而Zookeeper正好要用來進(jìn)行分布式環(huán)境的協(xié)調(diào)一一于是两芳，Zookeeper的名字也就由此誕生了摔寨。
ZooKeeper 是一個(gè)開源的分布式協(xié)調(diào)服務(wù)，ZooKeeper框架最初是在“Yahoo!"上構(gòu)建的怖辆，用于以簡單而穩(wěn)健的方式訪問他們的應(yīng)用程序是复。 后來，Apache ZooKeeper成為Hadoop竖螃，HBase和其他分布式框架使用的有組織服務(wù)的標(biāo)準(zhǔn)淑廊。 例如，Apache HBase使用ZooKeeper跟蹤分布式數(shù)據(jù)的狀態(tài)特咆。ZooKeeper 的設(shè)計(jì)目標(biāo)是將那些復(fù)雜且容易出錯(cuò)的分布式一致性服務(wù)封裝起來季惩，構(gòu)成一個(gè)高效可靠的原語集，并以一系列簡單易用的接口提供給用戶使用腻格。
原語：操作系統(tǒng)或計(jì)算機(jī)網(wǎng)絡(luò)用語范疇画拾。是由若干條指令組成的，用于完成一定功能的一個(gè)過程菜职。具有不可分割性·即原語的執(zhí)行必須是連續(xù)的青抛，在執(zhí)行過程中不允許被中斷。
ZooKeeper 是一個(gè)典型的分布式數(shù)據(jù)一致性解決方案酬核，分布式應(yīng)用程序可以基于 ZooKeeper 實(shí)現(xiàn)諸如數(shù)據(jù)發(fā)布/訂閱蜜另、負(fù)載均衡、命名服務(wù)愁茁、分布式協(xié)調(diào)/通知蚕钦、集群管理、Master 選舉鹅很、分布式鎖和分布式隊(duì)列等功能嘶居。
Zookeeper 一個(gè)最常用的使用場景就是用于擔(dān)任服務(wù)生產(chǎn)者和服務(wù)消費(fèi)者的注冊(cè)中心。服務(wù)生產(chǎn)者將自己提供的服務(wù)注冊(cè)到Zookeeper中心促煮，服務(wù)的消費(fèi)者在進(jìn)行服務(wù)調(diào)用的時(shí)候先到Zookeeper中查找服務(wù)邮屁，獲取到服務(wù)生產(chǎn)者的詳細(xì)信息之后，再去調(diào)用服務(wù)生產(chǎn)者的內(nèi)容與數(shù)據(jù)菠齿。如下圖所示佑吝，在 Dubbo架構(gòu)中 Zookeeper 就擔(dān)任了注冊(cè)中心這一角色。
Dubbo
1.2 結(jié)合個(gè)人使用情況的講一下 ZooKeeper
在我自己做過的項(xiàng)目中绳匀，主要使用到了 ZooKeeper 作為 Dubbo 的注冊(cè)中心(Dubbo 官方推薦使用 ZooKeeper注冊(cè)中心)芋忿。另外在搭建 solr 集群的時(shí)候炸客，我使用 ?ZooKeeper 作為 solr 集群的管理工具。這時(shí)戈钢，ZooKeeper 主要提供下面幾個(gè)功能：1痹仙、集群管理：容錯(cuò)、負(fù)載均衡殉了。2开仰、配置文件的集中管理3、集群的入口薪铜。
我個(gè)人覺得在使用 ZooKeeper 的時(shí)候众弓，最好是使用 集群版的 ZooKeeper 而不是單機(jī)版的。官網(wǎng)給出的架構(gòu)圖就描述的是一個(gè)集群版的 ZooKeeper 隔箍。通常 3 臺(tái)服務(wù)器就可以構(gòu)成一個(gè) ?ZooKeeper ?集群了谓娃。
為什么最好使用奇數(shù)臺(tái)服務(wù)器構(gòu)成 ZooKeeper 集群？
我們知道在Zookeeper中 Leader 選舉算法采用了Zab協(xié)議鞍恢。Zab核心思想是當(dāng)多數(shù) Server 寫成功傻粘，則任務(wù)數(shù)據(jù)寫成功。
①如果有3個(gè)Server帮掉，則最多允許1個(gè)Server 掛掉弦悉。
②如果有4個(gè)Server，則同樣最多允許1個(gè)Server掛掉蟆炊。
既然3個(gè)或者4個(gè)Server稽莉，同樣最多允許1個(gè)Server掛掉，那么它們的可靠性是一樣的涩搓，所以選擇奇數(shù)個(gè)ZooKeeper Server即可污秆，這里選擇3個(gè)Server。
ZooKeeper ?本身就是一個(gè)分布式程序（只要半數(shù)以上節(jié)點(diǎn)存活昧甘，ZooKeeper ?就能正常服務(wù)）良拼。
為了保證高可用，最好是以集群形態(tài)來部署 ZooKeeper充边，這樣只要集群中大部分機(jī)器是可用的（能夠容忍一定的機(jī)器故障）庸推，那么 ZooKeeper 本身仍然是可用的。
ZooKeeper ?將數(shù)據(jù)保存在內(nèi)存中浇冰，這也就保證了 高吞吐量和低延遲（但是內(nèi)存限制了能夠存儲(chǔ)的容量不太大贬媒，此限制也是保持znode中存儲(chǔ)的數(shù)據(jù)量較小的進(jìn)一步原因）。
ZooKeeper 是高性能的肘习。 在“讀”多于“寫”的應(yīng)用程序中尤其地高性能际乘，因?yàn)椤皩憽睍?huì)導(dǎo)致所有的服務(wù)器間同步狀態(tài)。（“讀”多于“寫”是協(xié)調(diào)服務(wù)的典型場景漂佩。）
ZooKeeper有臨時(shí)節(jié)點(diǎn)的概念脖含。 當(dāng)創(chuàng)建臨時(shí)節(jié)點(diǎn)的客戶端會(huì)話一直保持活動(dòng)罪塔，瞬時(shí)節(jié)點(diǎn)就一直存在。而當(dāng)會(huì)話終結(jié)時(shí)器赞，瞬時(shí)節(jié)點(diǎn)被刪除垢袱。持久節(jié)點(diǎn)是指一旦這個(gè)ZNode被創(chuàng)建了，除非主動(dòng)進(jìn)行ZNode的移除操作港柜，否則這個(gè)ZNode將一直保存在Zookeeper上。
ZooKeeper 底層其實(shí)只提供了兩個(gè)功能：①管理（存儲(chǔ)咳榜、讀认淖怼）用戶程序提交的數(shù)據(jù)；②為用戶程序提交數(shù)據(jù)節(jié)點(diǎn)監(jiān)聽服務(wù)涌韩。
下面關(guān)于會(huì)話（Session）畔柔、 Znode、版本臣樱、Watcher靶擦、ACL概念的總結(jié)都在《從Paxos到Zookeeper 》第四章第一節(jié)以及第七章第八節(jié)有提到，感興趣的可以看看雇毫！
Session 指的是 ZooKeeper ?服務(wù)器與客戶端會(huì)話玄捕。在 ZooKeeper 中，一個(gè)客戶端連接是指客戶端和服務(wù)器之間的一個(gè) TCP 長連接棚放∶墩常客戶端啟動(dòng)的時(shí)候，首先會(huì)與服務(wù)器建立一個(gè) TCP 連接飘蚯，從第一次連接建立開始馍迄，客戶端會(huì)話的生命周期也開始了。通過這個(gè)連接局骤，客戶端能夠通過心跳檢測與服務(wù)器保持有效的會(huì)話攀圈，也能夠向Zookeeper服務(wù)器發(fā)送請(qǐng)求并接受響應(yīng)，同時(shí)還能夠通過該連接接收來自服務(wù)器的Watch事件通知峦甩。Session的sessionTimeout值用來設(shè)置一個(gè)客戶端會(huì)話的超時(shí)時(shí)間赘来。當(dāng)由于服務(wù)器壓力太大、網(wǎng)絡(luò)故障或是客戶端主動(dòng)斷開連接等各種原因?qū)е驴蛻舳诉B接斷開時(shí)穴店，只要在sessionTimeout規(guī)定的時(shí)間內(nèi)能夠重新連接上集群中任意一臺(tái)服務(wù)器撕捍，那么之前創(chuàng)建的會(huì)話仍然有效。
在為客戶端創(chuàng)建會(huì)話之前泣洞，服務(wù)端首先會(huì)為每個(gè)客戶端都分配一個(gè)sessionID忧风。由于 sessionID 是 Zookeeper 會(huì)話的一個(gè)重要標(biāo)識(shí)，許多與會(huì)話相關(guān)的運(yùn)行機(jī)制都是基于這個(gè) sessionID 的球凰，因此狮腿，無論是哪臺(tái)服務(wù)器為客戶端分配的 sessionID腿宰，都務(wù)必保證全局唯一。
在談到分布式的時(shí)候缘厢，我們通常說的“節(jié)點(diǎn)"是指組成集群的每一臺(tái)機(jī)器吃度。然而，在Zookeeper中贴硫，“節(jié)點(diǎn)"分為兩類椿每，第一類同樣是指構(gòu)成集群的機(jī)器，我們稱之為機(jī)器節(jié)點(diǎn)英遭；第二類則是指數(shù)據(jù)模型中的數(shù)據(jù)單元间护，我們稱之為數(shù)據(jù)節(jié)點(diǎn)一一ZNode。
Zookeeper將所有數(shù)據(jù)存儲(chǔ)在內(nèi)存中挖诸，數(shù)據(jù)模型是一棵樹（Znode Tree)汁尺，由斜杠（/）的進(jìn)行分割的路徑，就是一個(gè)Znode多律，例如/foo/path1痴突。每個(gè)上都會(huì)保存自己的數(shù)據(jù)內(nèi)容，同時(shí)還會(huì)保存一系列屬性信息狼荞。
在Zookeeper中辽装，node可以分為持久節(jié)點(diǎn)和臨時(shí)節(jié)點(diǎn)兩類。所謂持久節(jié)點(diǎn)是指一旦這個(gè)ZNode被創(chuàng)建了粘秆，除非主動(dòng)進(jìn)行ZNode的移除操作如迟，否則這個(gè)ZNode將一直保存在Zookeeper上。而臨時(shí)節(jié)點(diǎn)就不一樣了攻走，它的生命周期和客戶端會(huì)話綁定殷勘，一旦客戶端會(huì)話失效，那么這個(gè)客戶端創(chuàng)建的所有臨時(shí)節(jié)點(diǎn)都會(huì)被移除昔搂。另外玲销，ZooKeeper還允許用戶為每個(gè)節(jié)點(diǎn)添加一個(gè)特殊的屬性：SEQUENTIAL.一旦節(jié)點(diǎn)被標(biāo)記上這個(gè)屬性，那么在這個(gè)節(jié)點(diǎn)被創(chuàng)建的時(shí)候摘符，Zookeeper會(huì)自動(dòng)在其節(jié)點(diǎn)名后面追加上一個(gè)整型數(shù)字贤斜，這個(gè)整型數(shù)字是一個(gè)由父節(jié)點(diǎn)維護(hù)的自增數(shù)字。
在前面我們已經(jīng)提到逛裤，Zookeeper 的每個(gè) ZNode 上都會(huì)存儲(chǔ)數(shù)據(jù)瘩绒，對(duì)應(yīng)于每個(gè)ZNode，Zookeeper 都會(huì)為其維護(hù)一個(gè)叫作Stat的數(shù)據(jù)結(jié)構(gòu)带族，Stat中記錄了這個(gè) ZNode 的三個(gè)數(shù)據(jù)版本锁荔，分別是version（當(dāng)前ZNode的版本）、cversion（當(dāng)前ZNode子節(jié)點(diǎn)的版本）和 cversion（當(dāng)前ZNode的ACL版本）蝙砌。
Watcher（事件監(jiān)聽器）阳堕，是Zookeeper中的一個(gè)很重要的特性跋理。Zookeeper允許用戶在指定節(jié)點(diǎn)上注冊(cè)一些Watcher，并且在一些特定事件觸發(fā)的時(shí)候恬总，ZooKeeper服務(wù)端會(huì)將事件通知到感興趣的客戶端上去前普，該機(jī)制是Zookeeper實(shí)現(xiàn)分布式協(xié)調(diào)服務(wù)的重要特性。
Zookeeper采用ACL（AccessControlLists）策略來進(jìn)行權(quán)限控制壹堰，類似于 UNIX 文件系統(tǒng)的權(quán)限控制拭卿。Zookeeper 定義了如下5種權(quán)限。
其中尤其需要注意的是缀旁，CREATE和DELETE這兩種權(quán)限都是針對(duì)子節(jié)點(diǎn)的權(quán)限控制记劈。
順序一致性：從同一客戶端發(fā)起的事務(wù)請(qǐng)求，最終將會(huì)嚴(yán)格地按照順序被應(yīng)用到 ZooKeeper 中去并巍。
原子性：所有事務(wù)請(qǐng)求的處理結(jié)果在整個(gè)集群中所有機(jī)器上的應(yīng)用情況是一致的，也就是說换途，要么整個(gè)集群中所有的機(jī)器都成功應(yīng)用了某一個(gè)事務(wù)懊渡，要么都沒有應(yīng)用。
單一系統(tǒng)映像 ：無論客戶端連到哪一個(gè) ZooKeeper 服務(wù)器上军拟，其看到的服務(wù)端數(shù)據(jù)模型都是一致的剃执。
可靠性：一旦一次更改請(qǐng)求被應(yīng)用，更改的結(jié)果就會(huì)被持久化懈息，直到被下一次更改覆蓋肾档。
四 ZooKeeper 設(shè)計(jì)目標(biāo)
ZooKeeper 允許分布式進(jìn)程通過共享的層次結(jié)構(gòu)命名空間進(jìn)行相互協(xié)調(diào)，這與標(biāo)準(zhǔn)文件系統(tǒng)類似辫继。 名稱空間由 ZooKeeper 中的數(shù)據(jù)寄存器組成 - 稱為znode怒见，這些類似于文件和目錄。 與為存儲(chǔ)設(shè)計(jì)的典型文件系統(tǒng)不同姑宽，ZooKeeper數(shù)據(jù)保存在內(nèi)存中属铁，這意味著ZooKeeper可以實(shí)現(xiàn)高吞吐量和低延遲草描。
為了保證高可用，最好是以集群形態(tài)來部署 ZooKeeper，這樣只要集群中大部分機(jī)器是可用的（能夠容忍一定的機(jī)器故障）奢浑，那么zookeeper本身仍然是可用的。客戶端在使用 ZooKeeper 時(shí)抡柿，需要知道集群機(jī)器列表遍膜，通過與集群中的某一臺(tái)機(jī)器建立 TCP 連接來使用服務(wù)，客戶端使用這個(gè)TCP鏈接來發(fā)送請(qǐng)求扛或、獲取結(jié)果绵咱、獲取監(jiān)聽事件以及發(fā)送心跳包。如果這個(gè)連接異常斷開了告喊，客戶端可以連接到另外的機(jī)器上麸拄。
ZooKeeper 官方提供的架構(gòu)圖：
上圖中每一個(gè)Server代表一個(gè)安裝Zookeeper服務(wù)的服務(wù)器派昧。組成 ZooKeeper 服務(wù)的服務(wù)器都會(huì)在內(nèi)存中維護(hù)當(dāng)前的服務(wù)器狀態(tài)，并且每臺(tái)服務(wù)器之間都互相保持著通信拢切。集群間通過 Zab 協(xié)議（Zookeeper Atomic Broadcast）來保持?jǐn)?shù)據(jù)的一致性蒂萎。
對(duì)于來自客戶端的每個(gè)更新請(qǐng)求，ZooKeeper 都會(huì)分配一個(gè)全局唯一的遞增編號(hào)淮椰，這個(gè)編號(hào)反應(yīng)了所有事務(wù)操作的先后順序五慈，應(yīng)用程序可以使用 ZooKeeper 這個(gè)特性來實(shí)現(xiàn)更高層次的同步原語。這個(gè)編號(hào)也叫做時(shí)間戳——zxid（Zookeeper Transaction Id）
ZooKeeper 是高性能的主穗。 在“讀”多于“寫”的應(yīng)用程序中尤其地高性能泻拦，因?yàn)椤皩憽睍?huì)導(dǎo)致所有的服務(wù)器間同步狀態(tài)。（“讀”多于“寫”是協(xié)調(diào)服務(wù)的典型場景忽媒。）
最典型集群模式： Master/Slave 模式（主備模式）争拐。在這種模式中，通常 Master服務(wù)器作為主服務(wù)器提供寫服務(wù)晦雨，其他的 Slave 服務(wù)器從服務(wù)器通過異步復(fù)制的方式獲取 Master 服務(wù)器最新的數(shù)據(jù)提供讀服務(wù)架曹。
但是，在 ZooKeeper 中沒有選擇傳統(tǒng)的 ?Master/Slave 概念闹瞧，而是引入了Leader绑雄、Follower 和 Observer 三種角色。如下圖所示
ZooKeeper 集群中的所有機(jī)器通過一個(gè) Leader 選舉過程來選定一臺(tái)稱為 “Leader” 的機(jī)器奥邮，Leader 既可以為客戶端提供寫服務(wù)又能提供讀服務(wù)万牺。除了 Leader 外，F(xiàn)ollower 和 ?Observer 都只能提供讀服務(wù)洽腺。Follower 和 ?Observer 唯一的區(qū)別在于 Observer 機(jī)器不參與 Leader 的選舉過程脚粟，也不參與寫操作的“過半寫成功”策略，因此 Observer 機(jī)器可以在不影響寫性能的情況下提升集群的讀性能已脓。
六 ZooKeeper &ZAB 協(xié)議&Paxos算法
Paxos 算法應(yīng)該可以說是 ?ZooKeeper 的靈魂了珊楼。但是，ZooKeeper 并沒有完全采用 Paxos算法 度液，而是使用 ZAB 協(xié)議作為其保證數(shù)據(jù)一致性的核心算法厕宗。另外，在ZooKeeper的官方文檔中也指出堕担，ZAB協(xié)議并不像 Paxos 算法那樣已慢，是一種通用的分布式一致性算法，它是一種特別為Zookeeper設(shè)計(jì)的崩潰可恢復(fù)的原子消息廣播算法霹购。
ZAB（ZooKeeper Atomic Broadcast 原子廣播） 協(xié)議是為分布式協(xié)調(diào)服務(wù) ZooKeeper 專門設(shè)計(jì)的一種支持崩潰恢復(fù)的原子廣播協(xié)議佑惠。 在 ZooKeeper 中，主要依賴 ZAB 協(xié)議來實(shí)現(xiàn)分布式數(shù)據(jù)一致性，基于該協(xié)議膜楷，ZooKeeper 實(shí)現(xiàn)了一種主備模式的系統(tǒng)架構(gòu)來保持集群中各個(gè)副本之間的數(shù)據(jù)一致性旭咽。
6.3 ZAB 協(xié)議兩種基本的模式：崩潰恢復(fù)和消息廣播
ZAB協(xié)議包括兩種基本的模式，分別是崩潰恢復(fù)和消息廣播赌厅。當(dāng)整個(gè)服務(wù)框架在啟動(dòng)過程中穷绵，或是當(dāng) Leader 服務(wù)器出現(xiàn)網(wǎng)絡(luò)中斷、崩潰退出與重啟等異常情況時(shí)特愿，ZAB 協(xié)議就會(huì)進(jìn)人恢復(fù)模式并選舉產(chǎn)生新的Leader服務(wù)器仲墨。當(dāng)選舉產(chǎn)生了新的 Leader 服務(wù)器，同時(shí)集群中已經(jīng)有過半的機(jī)器與該Leader服務(wù)器完成了狀態(tài)同步之后揍障，ZAB協(xié)議就會(huì)退出恢復(fù)模式目养。其中，所謂的狀態(tài)同步是指數(shù)據(jù)同步毒嫡，用來保證集群中存在過半的機(jī)器能夠和Leader服務(wù)器的數(shù)據(jù)狀態(tài)保持一致癌蚁。
當(dāng)集群中已經(jīng)有過半的Follower服務(wù)器完成了和Leader服務(wù)器的狀態(tài)同步，那么整個(gè)服務(wù)框架就可以進(jìn)人消息廣播模式了兜畸。當(dāng)一臺(tái)同樣遵守ZAB協(xié)議的服務(wù)器啟動(dòng)后加人到集群中時(shí)匈勋，如果此時(shí)集群中已經(jīng)存在一個(gè)Leader服務(wù)器在負(fù)責(zé)進(jìn)行消息廣播，那么新加人的服務(wù)器就會(huì)自覺地進(jìn)人數(shù)據(jù)恢復(fù)模式：找到Leader所在的服務(wù)器膳叨，并與其進(jìn)行數(shù)據(jù)同步，然后一起參與到消息廣播流程中去痘系。正如上文介紹中所說的菲嘴，ZooKeeper設(shè)計(jì)成只允許唯一的一個(gè)Leader服務(wù)器來進(jìn)行事務(wù)請(qǐng)求的處理。Leader服務(wù)器在接收到客戶端的事務(wù)請(qǐng)求后汰翠，會(huì)生成對(duì)應(yīng)的事務(wù)提案并發(fā)起一輪廣播協(xié)議龄坪；而如果集群中的其他機(jī)器接收到客戶端的事務(wù)請(qǐng)求，那么這些非Leader服務(wù)器會(huì)首先將這個(gè)事務(wù)請(qǐng)求轉(zhuǎn)發(fā)給Leader服務(wù)器复唤。
關(guān)于ZAB 協(xié)議&Paxos算法需要講和理解的東西太多了健田，說實(shí)話，筆主到現(xiàn)在不太清楚這倆兄弟的具體原理和實(shí)現(xiàn)過程佛纫。推薦閱讀下面兩篇文章：
圖解 Paxos 一致性協(xié)議:
http://blog.xiaohansong.com/2016/09/30/Paxos/
Zookeeper ZAB 協(xié)議分析:
推薦一個(gè)交流學(xué)習(xí)群：777158424 里面會(huì)分享一些資深架構(gòu)師錄制的視頻錄像：有Spring妓局，MyBatis，Netty源碼分析呈宇，高并發(fā)好爬、高性能、分布式甥啄、微服務(wù)架構(gòu)的原理存炮，JVM性能優(yōu)化這些成為架構(gòu)師必備的知識(shí)體系。還能領(lǐng)取免費(fèi)的學(xué)習(xí)資源，目前受益良多
---------------------本文來自 張大春 的CSDN 博客 穆桂，全文地址請(qǐng)點(diǎn)擊：https://blog.csdn.net/qq_39627461/article/details/82890685?utm_source=copy
