序言
??Apache ZooKeeper是由集群（節(jié)點組）使用的一種服務(wù)瘟判，用于在自身之間協(xié)調(diào)怨绣，并通過穩(wěn)健的同步技術(shù)維護共享數(shù)據(jù)。ZooKeeper本身是一個分布式應(yīng)用程序拷获，為寫入分布式應(yīng)用程序提供服務(wù)篮撑。
1.zookeeper特性
- 一致性:數(shù)據(jù)一致性，數(shù)據(jù)按照順序分批入庫匆瓜。
- 原子性:事務(wù)要么成功要么失敗赢笨，不會局部化未蝌。
- 單一視圖:客戶端連接集群中任一zk節(jié)點，數(shù)據(jù)都是一致的茧妒。
- 可靠性:每次對zk的操作狀態(tài)都會保存在服務(wù)端萧吠。
- 實時性:客戶端可以讀取到zk服務(wù)器的最新數(shù)據(jù)。
2.zookeeper應(yīng)用場景
2.1 數(shù)據(jù)發(fā)布與訂閱
??發(fā)布與訂閱即所謂的配置管理桐筏，顧名思義就是有系統(tǒng)將數(shù)據(jù)發(fā)布到zk節(jié)點上纸型，供訂閱者動態(tài)獲取數(shù)據(jù)，實現(xiàn)配置信息的集中式管理和動態(tài)更新梅忌。例如全局的配置信息狰腌，地址列表等就非常適合使用。(Diamond和ConfigServer在這方面也具備功能)
應(yīng)用中的具體使用
- 索引信息和集群中機器節(jié)點狀態(tài)存放在zk的一些指定節(jié)點牧氮，供各個客戶端使用;
- 系統(tǒng)日志(經(jīng)過處理后的)存儲琼腔，這些日志通常2-3天后被清除;
- 應(yīng)用中用到的一些配置信息集中管理，在應(yīng)用啟動的時候主動來獲取一次踱葛，并且在節(jié)點上注冊一個Watcher丹莲，以后每次配置有更新，實時通知到應(yīng)用剖毯。
- 業(yè)務(wù)邏輯中需要用到的一些全局變量圾笨，比如一些消息中間件的消息隊列通常有個offset，這個offset存放在zk上逊谋，這樣集群中每個發(fā)送者都能知道當(dāng)前的發(fā)送進度
- 系統(tǒng)中有些信息需要動態(tài)獲取擂达，并且還會存在人工手動去修改這個信息。以前通常是暴露出接口胶滋，例如JMX接口板鬓，有了zk后，只要將這些信息存放到zk節(jié)點上即可究恤。
2.2 分布通知/協(xié)調(diào)
??ZooKeeper中特有watcher注冊與異步通知機制俭令，能夠很好的實現(xiàn)分布式環(huán)境下不同系統(tǒng)之間的通知與協(xié)調(diào)，實現(xiàn)對數(shù)據(jù)變更的實時處理部宿。
??使用方法:通常是不同系統(tǒng)都對ZK上同一個znode進行注冊抄腔，監(jiān)聽znode的變化(包括znode本身內(nèi)容及子節(jié)點的)，其中一個系統(tǒng)update了znode理张，那么另一個系統(tǒng)能夠收到通知赫蛇，并作出相應(yīng)處理。
2.3 分布式鎖
??分布式鎖雾叭，這個主要得益于ZooKeeper為我們保證了強一致性悟耘，即用戶只要完全信任每時每刻，zk集群中任意節(jié)點(一個zk server)上的相同znode的數(shù)據(jù)是一定是相同的织狐。
鎖服務(wù)可以分為兩類: 一個是保持獨占暂幼，另一個是控制時序筏勒。
2.4 集群管理
Hbase Master選舉則是zookeeper經(jīng)典的使用場景；
Storm集群管理;
2.5 分布式隊列
3. Zookeeper架構(gòu)(Architecture)
看看下面的圖表旺嬉。它描述了ZooKeeper的“客戶端-服務(wù)器架構(gòu)”管行。
作為ZooKeeper架構(gòu)的一部分的每個組件在下表中進行了說明。
| 部分 | 描述 |
|---|---|
| Client(客戶端) | 客戶端鹰服，我們的分布式應(yīng)用集群中的一個節(jié)點病瞳，從服務(wù)器訪問信息揽咕。對于特定的時間間隔悲酷，每個客戶端向服務(wù)器發(fā)送消息以使服務(wù)器知道客戶端是活躍的。類似地亲善，當(dāng)客戶端連接時设易，服務(wù)器發(fā)送確認(rèn)碼。如果連接的服務(wù)器沒有響應(yīng)蛹头，客戶端會自動將消息重定向到另一個服務(wù)器顿肺。 |
| Server(服務(wù)器) | 服務(wù)器，我們的ZooKeeper總體中的一個節(jié)點渣蜗，為客戶端提供所有的服務(wù)屠尊。向客戶端發(fā)送確認(rèn)碼以告知服務(wù)器是活躍的。 |
| Ensemble | ZooKeeper服務(wù)器組耕拷。形成ensemble所需的最小節(jié)點數(shù)為3讼昆。 |
| Leader | 服務(wù)器節(jié)點，如果任何連接的節(jié)點失敗骚烧，則執(zhí)行自動恢復(fù)浸赫。Leader在服務(wù)啟動時被選舉。 |
| Follower | 跟隨leader指令的服務(wù)器節(jié)點赃绊。 |
4.Zookeeper層次命名空間
下圖描述了用于內(nèi)存表示的ZooKeeper文件系統(tǒng)的樹結(jié)構(gòu)既峡。ZooKeeper節(jié)點稱為 znode 。每個znode由一個名稱標(biāo)識碧查，并用路徑(/)序列分隔运敢。
- 在圖中，首先有一個由“/”分隔的znode忠售。在根目錄下传惠，你有兩個邏輯命名空間 config 和 workers。
- config 命名空間用于集中式配置管理档痪，workers 命名空間用于命名涉枫。
- 在 config 命名空間下，每個znode最多可存儲1MB的數(shù)據(jù)腐螟。這與UNIX文件系統(tǒng)相類似愿汰，除了父znode也可以存儲數(shù)據(jù)困后。這種結(jié)構(gòu)的主要目的是存儲同步數(shù)據(jù)并描述znode的元數(shù)據(jù)则酝。此結(jié)構(gòu)稱為 ZooKeeper數(shù)據(jù)模型晋辆。
ZooKeeper數(shù)據(jù)模型中的每個znode都維護著一個 stat 結(jié)構(gòu)。一個stat僅提供一個znode的元數(shù)據(jù)西潘。它由版本號吗跋，操作控制列表(ACL)侧戴，時間戳和數(shù)據(jù)長度組成。
- 版本號: 每個znode都有版本號跌宛，這意味著每當(dāng)與znode相關(guān)聯(lián)的數(shù)據(jù)發(fā)生變化時酗宋，其對應(yīng)的版本號也會增加。當(dāng)多個zookeeper客戶端嘗試在同一znode上執(zhí)行操作時疆拘，版本號的使用就很重要蜕猫。
- 操作控制列表(ACL): ACL基本上是訪問znode的認(rèn)證機制。它管理所有znode讀取和寫入操作哎迄。
- 時間戳: 時間戳表示創(chuàng)建和修改znode所經(jīng)過的時間回右。它通常以毫秒為單位。ZooKeeper從“事務(wù)ID"(zxid)標(biāo)識znode的每個更改漱挚。Zxid 是唯一的翔烁，并且為每個事務(wù)保留時間，以便你可以輕松地確定從一個請求到另一個請求所經(jīng)過的時間旨涝。
- 數(shù)據(jù)長度: 存儲在znode中的數(shù)據(jù)總量是數(shù)據(jù)長度蹬屹。你最多可以存儲1MB的數(shù)據(jù)。
Znode的類型
Znode被分為持久（persistent）節(jié)點颊糜，順序（sequential）節(jié)點和臨時（ephemeral）節(jié)點哩治。
- 持久節(jié)點: 即使在創(chuàng)建該特定znode的客戶端斷開連接后，持久節(jié)點仍然存在衬鱼。默認(rèn)情況下业筏，除非另有說明，否則所有znode都是持久的鸟赫。
- 臨時節(jié)點: 客戶端活躍時蒜胖，臨時節(jié)點就是有效的。當(dāng)客戶端與ZooKeeper集合斷開連接時抛蚤，臨時節(jié)點會自動刪除台谢。注意: 因此，只有臨時節(jié)點不允許有子節(jié)點岁经。如果臨時節(jié)點被刪除朋沮，則下一個合適的節(jié)點將填充其位置。臨時節(jié)點在leader選舉中起著重要作用缀壤。
- 順序節(jié)點: 順序節(jié)點可以是持久的或臨時的樊拓。當(dāng)一個新的znode被創(chuàng)建為一個順序節(jié)點時纠亚，ZooKeeper通過將10位的序列號附加到原始名稱來設(shè)置znode的路徑。例如筋夏，如果將具有路徑 /myapp 的znode創(chuàng)建為順序節(jié)點蒂胞，則ZooKeeper會將路徑更改為 /myapp0000000001 ，并將下一個序列號設(shè)置為0000000002条篷。如果兩個順序節(jié)點是同時創(chuàng)建的骗随，那么ZooKeeper不會對每個znode使用相同的數(shù)字。順序節(jié)點在鎖定和同步中起重要作用赴叹。
5. Sessions（會話）
會話對于ZooKeeper的操作非常重要鸿染。會話中的請求按FIFO順序執(zhí)行。一旦客戶端連接到服務(wù)器稚瘾，將建立會話并向客戶端分配會話ID 牡昆。
客戶端以特定的時間間隔發(fā)送心跳以保持會話有效姚炕。如果ZooKeeper集合在超過服務(wù)器開啟時指定的期間（會話超時）都沒有從客戶端接收到心跳摊欠，則它會判定客戶端死機。
會話超時通常以毫秒為單位柱宦。當(dāng)會話由于任何原因結(jié)束時些椒，在該會話期間創(chuàng)建的臨時節(jié)點也會被刪除。
6 Watches（監(jiān)視）
監(jiān)視是一種簡單的機制掸刊，使客戶端收到關(guān)于ZooKeeper集合中的更改的通知免糕。客戶端可以在讀取特定znode時設(shè)置Watches忧侧。Watches會向注冊的客戶端發(fā)送任何znode（客戶端注冊表）更改的通知石窑。
Znode更改: 是與znode相關(guān)的數(shù)據(jù)的修改或znode的子項中的更改。
只觸發(fā)一次watches: 如果客戶端想要再次通知蚓炬，則必須通過另一個讀取操作來完成松逊。
連接會話過期時: 客戶端將與服務(wù)器斷開連接，相關(guān)的watches也將被刪除肯夏。
7. Zookeeper 工作流
ZAB協(xié)議
Zookeeper的核心是原子廣播,這個機制保證了各個Server之間的同步经宏。實現(xiàn)這個機制的協(xié)議叫做Zab協(xié)議.
Zab協(xié)議有兩種模式，它們分別是恢復(fù)模式（選主:leader election）和廣播模式（同步:Atomic broadcast）驯击。
當(dāng)服務(wù)啟動或者在領(lǐng)導(dǎo)者崩潰后烁兰，Zab就進入了恢復(fù)模式，當(dāng)領(lǐng)導(dǎo)者被選舉出來徊都，且大多數(shù)Server完成了和leader的狀態(tài)同步以后,恢復(fù)模式就結(jié)束了沪斟。狀態(tài)同步保證了leader和Server具有相同的系統(tǒng)狀態(tài)。
paxos算法
在一個分布式數(shù)據(jù)庫系統(tǒng)中暇矫，如果各節(jié)點的初始狀態(tài)一致主之，每個節(jié)點都執(zhí)行相同的操作序列轨域，那么他們最后能得到一個一致的狀態(tài);
Paxos算法解決的什么問題
解決的就是保證每個節(jié)點執(zhí)行相同的操作序列。好吧杀餐，這還不簡單干发，master維護一個全局寫隊列，所有寫操作都必須 放入這個隊列編號史翘，那么無論我們寫多少個節(jié)點枉长，只要寫操作是按編號來的，就能保證一致性琼讽。
Paxos算法通過投票來對寫操作進行全局編號必峰，同一時刻，只有一個寫操作被批準(zhǔn)钻蹬，同時并發(fā)的寫操作要去爭取選票吼蚁，只有獲得過半數(shù)選票的寫操作才會被 批準(zhǔn)（所以永遠(yuǎn)只會有一個寫操作得到批準(zhǔn)），其他的寫操作競爭失敗只好再發(fā)起一輪投票问欠，就這樣肝匆，在日復(fù)一日年復(fù)一年的投票中，所有寫操作都被嚴(yán)格編號排 序顺献。編號嚴(yán)格遞增旗国，當(dāng)一個節(jié)點接受了一個編號為100的寫操作，之后又接受到編號為99的寫操作（因為網(wǎng)絡(luò)延遲等很多不可預(yù)見原因）注整，它馬上能意識到自己 數(shù)據(jù)不一致了能曾，自動停止對外服務(wù)并重啟同步過程。任何一個節(jié)點掛掉都不會影響整個集群的數(shù)據(jù)一致性（總2n+1臺肿轨，除非掛掉大于n臺）寿冕。
ZooKeeper集合啟動，它將等待客戶端連接椒袍⊥粘客戶端將連接到ZooKeeper集合中的一個節(jié)點。它可以是leader或follower節(jié)點槐沼。一旦客戶端被連接曙蒸，節(jié)點將向特定客戶端分配會話ID并向該客戶端發(fā)送確認(rèn)。如果客戶端沒有收到確認(rèn)岗钩，它將嘗試連接ZooKeeper集合中的另一個節(jié)點纽窟。 一旦連接到節(jié)點，客戶端將以有規(guī)律的間隔向節(jié)點發(fā)送心跳兼吓，以確保連接不會丟失臂港。
- 如果客戶端想要讀取特定的znode，它將會向具有znode路徑的節(jié)點發(fā)送讀取請求，并且節(jié)點通過從其自己的數(shù)據(jù)庫獲取來返回所請求的znode审孽。為此县袱，在ZooKeeper集合中讀取速度很快。
- 如果客戶端想要將數(shù)據(jù)存儲在ZooKeeper集合中佑力，則會將znode路徑和數(shù)據(jù)發(fā)送到服務(wù)器式散。連接的服務(wù)器將該請求轉(zhuǎn)發(fā)給leader，然后leader將向所有的follower重新發(fā)出寫入請求打颤。如果只有大部分節(jié)點成功響應(yīng)暴拄，而寫入請求成功，則成功返回代碼將被發(fā)送到客戶端编饺。 否則乖篷，寫入請求失敗。絕大多數(shù)節(jié)點被稱為 Quorum 透且。
下圖描述了ZooKeeper工作流撕蔼，后面的表說明了它的不同組件。
| 組件 | 描述 |
|---|---|
| 寫入(write) | 寫入過程由leader節(jié)點處理秽誊。leader將寫入請求轉(zhuǎn)發(fā)到所有znode鲸沮，并等待znode的回復(fù)。如果一半的znode回復(fù)养距，則寫入過程完成诉探。 |
| 讀取(read) | 讀取由特定連接的znode在內(nèi)部執(zhí)行，因此不需要與集群進行交互棍厌。 |
| 復(fù)制數(shù)據(jù)庫(replicated database) | 它用于在zookeeper中存儲數(shù)據(jù)。每個znode都有自己的數(shù)據(jù)庫竖席，每個znode在一致性的幫助下每次都有相同的數(shù)據(jù)耘纱。 |
| Leader | Leader是負(fù)責(zé)處理寫入請求的Znode。 |
| Follower | follower從客戶端接收寫入請求毕荐，并將它們轉(zhuǎn)發(fā)到leader znode束析。 |
| 請求處理器(request processor) | 只存在于leader節(jié)點。它管理來自follower節(jié)點的寫入請求憎亚。 |
| 原子廣播(atomic broadcasts) | 負(fù)責(zé)廣播從leader節(jié)點到follower節(jié)點的變化员寇。 |
ZooKeeper集合中的節(jié)點
分析在ZooKeeper集合中擁有不同數(shù)量的節(jié)點的效果。
- 如果我們有單個節(jié)點第美，則當(dāng)該節(jié)點故障時蝶锋，ZooKeeper集合將故障。它有助于“單點故障"什往，不建議在生產(chǎn)環(huán)境中使用扳缕。
- 如果我們有兩個節(jié)點而一個節(jié)點故障，我們沒有占多數(shù)，因為兩個中的一個不是多數(shù)躯舔。
- 如果我們有三個節(jié)點而一個節(jié)點故障驴剔，那么我們有大多數(shù)，因此粥庄，這是最低要求丧失。ZooKeeper集合在實際生產(chǎn)環(huán)境中必須至少有三個節(jié)點。
- 如果我們有四個節(jié)點而兩個節(jié)點故障惜互，它將再次故障利花。類似于有三個節(jié)點，額外節(jié)點不用于任何目的载佳，因此炒事，最好添加奇數(shù)的節(jié)點，例如3蔫慧，5挠乳，7。
我們知道寫入過程比ZooKeeper集合中的讀取過程要貴姑躲，因為所有節(jié)點都需要在數(shù)據(jù)庫中寫入相同的數(shù)據(jù)睡扬。因此，對于平衡的環(huán)境擁有較少數(shù)量（例如3黍析，5卖怜，7）的節(jié)點比擁有大量的節(jié)點要好
8. Zookeeper leader選舉
讓我們分析如何在ZooKeeper集合中選舉leader節(jié)點〔妫考慮一個集群中有N個節(jié)點马靠。leader選舉的過程如下：
- 1.所有節(jié)點創(chuàng)建具有相同路徑 /app/leader_election/guid_ 的順序、臨時節(jié)點蔼两。
- 2.ZooKeeper集合將附加10位序列號到路徑甩鳄，創(chuàng)建的znode將是 /app/leader_election/guid_0000000001，/app/leader_election/guid_0000000002等额划。
- 3.對于給定的實例妙啃，在znode中創(chuàng)建最小數(shù)字的節(jié)點成為leader，而所有其他節(jié)點是follower俊戳。
- 4.每個follower節(jié)點監(jiān)視下一個具有最小數(shù)字的znode揖赴。例如，創(chuàng)建znode/app/leader_election/guid_0000000008的節(jié)點將監(jiān)視znode/app/leader_election/guid_0000000007抑胎，創(chuàng)建znode/app/leader_election/guid_0000000007的節(jié)點將監(jiān)視znode/app/leader_election/guid_0000000006燥滑。
- 5.如果leader關(guān)閉，則其相應(yīng)的znode/app/leader_electionN會被刪除圆恤。
- 6.下一個在線follower節(jié)點將通過監(jiān)視器獲得關(guān)于leader移除的通知突倍。
- 7.下一個在線follower節(jié)點將檢查是否存在其他具有最小數(shù)字的znode腔稀。如果沒有，那么它將承擔(dān)leader的角色羽历。否則焊虏，它找到的創(chuàng)建具有最小數(shù)字的znode的節(jié)點將作為leader。
- 8.類似地秕磷，所有其他follower節(jié)點選舉創(chuàng)建具有最小數(shù)字的znode的節(jié)點作為leader诵闭。
leader選舉是一個復(fù)雜的過程，但ZooKeeper服務(wù)使它非常簡單澎嚣。
9.Zookeeper Cli
ZooKeeper命令行界面(CLI): 用于與ZooKeeper集合進行交互以進行開發(fā)疏尿。它有助于調(diào)試和解決不同的選項。
要執(zhí)行ZooKeeper CLI操作易桃，首先打開ZooKeeper服務(wù)器（“bin/zkServer.sh start”）褥琐，然后打開ZooKeeper客戶端（“bin/zkCli.sh”）。一旦客戶端啟動晤郑，你可以執(zhí)行以下操作：
| 執(zhí)行功能 | 語法 | 特點 |
|---|---|---|
| 創(chuàng)建znode |
持久節(jié)點 create /path /data 順序節(jié)點 create -s /path /data 臨時節(jié)點 create -e /path /data |
順序節(jié)點: 保證znode路徑將是唯一的 臨時節(jié)點: 當(dāng)會話過期或客戶端斷開連接時敌呈，臨時節(jié)點將被自動刪除。 |
| 獲取數(shù)據(jù) | get /path |
順序節(jié)點: 訪問時必須輸入znode的完整路徑造寝。eg:get /FirstZnode0000000001 |
| 監(jiān)視znode的變化 | get /path [watch] 1 eg:get /FirstZnode 1 | 當(dāng)指定的znode或znode的子數(shù)據(jù)更改時磕洪，監(jiān)視器會顯示通知。你只能在 get 命令中設(shè)置watch诫龙。 輸出類似于普通的 get 命令析显，但它會等待后臺等待znode更改。 |
| 設(shè)置數(shù)據(jù) | set /path /data | 如果此znote節(jié)點設(shè)置了監(jiān)視,執(zhí)行命令后,監(jiān)視此節(jié)點的客戶端會收到通知 |
| 創(chuàng)建znode的子節(jié)點 | create /parent/path/subnode/path /data | 創(chuàng)建子節(jié)點類似于創(chuàng)建新的znode签赃。唯一的區(qū)別是谷异，子znode的路徑也將具有父路徑。 |
| 列出znode的子節(jié)點 | ls /path | 此命令用于列出和顯示znode的子項姊舵。 |
| 檢查狀態(tài) | stat /path | 狀態(tài)描述指定的znode的元數(shù)據(jù)晰绎。它包含時間戳，版本號括丁，ACL，數(shù)據(jù)長度和子znode等細(xì)項伶选。 |
| 移除/刪除znode | 移除 rmr /path 刪除 delete/path |
rmr /path : 移除指定的znode并遞歸其所有子節(jié)點 delete/path : 命令類似于 remove 命令史飞，除了它只適用于沒有子節(jié)點的znode。 |
舉個監(jiān)聽通知的例子,當(dāng)我們監(jiān)聽的節(jié)點數(shù)據(jù)有變動的時候,客戶端會收到通知如下
[zk: localhost:2181(CONNECTED) 1] get /FirstZnode “Mysecondzookeeper-app"
WATCHER: :
WatchedEvent state:SyncConnected type:NodeDataChanged path:/FirstZnode
cZxid = 0x7f
ctime = Tue Sep 29 16:15:47 IST 2015
mZxid = 0x84
mtime = Tue Sep 29 17:14:47 IST 2015
pZxid = 0x7f
cversion = 0
dataVersion = 1
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 23
numChildren = 0
| 屬性 | 解釋 |
|---|---|
| WatchedEvent | state: type: path: |
| cZxid | 對應(yīng)為該節(jié)點的創(chuàng)建時間(Create):創(chuàng)建節(jié)點時的事務(wù)ID |
| ctime | 創(chuàng)建節(jié)點時的時間 |
| mZxid | 對應(yīng)該節(jié)點的最近一次修改的時間(Mofify):最后修改節(jié)點時的事務(wù)ID |
| mtime | 最后修改節(jié)點時的時間 |
| pZxid | 表示該節(jié)點的子節(jié)點列表最后一次修改的事務(wù)ID仰税，添加子節(jié)點或刪除子節(jié)點就會影響子節(jié)點列表构资，但是修改子節(jié)點的數(shù)據(jù)內(nèi)容則不影響該ID; |
| cversion | 子節(jié)點版本號，子節(jié)點每次修改版本號加1 |
| dataVersion | 數(shù)據(jù)版本號陨簇，數(shù)據(jù)每次修改該版本號加1 |
| aclVersion | 權(quán)限版本號吐绵，權(quán)限每次修改該版本號加1 |
| ephemeralOwner | - |
| dataLength | 該節(jié)點的數(shù)據(jù)長度 |
| numChildren | 該節(jié)點擁有子節(jié)點的數(shù)量 |
znote版本號作用
普及悲觀鎖 | 樂觀鎖
- 悲觀鎖：它會假定所有不同事務(wù)的處理一定會出現(xiàn)干擾，數(shù)據(jù)庫中最嚴(yán)格的并發(fā)控制策略，如果一個事務(wù)A正在對數(shù)據(jù)處理己单，那么在整個事務(wù)過程中唉窃，其他事務(wù)都無法對這個數(shù)據(jù)進行更新操作，直到A事務(wù)釋放了這個鎖纹笼。
- 樂觀鎖：它假定所有不同事務(wù)的處理不一定會出現(xiàn)干擾纹份，所以在大部分操作里不許加鎖，但是既然是并發(fā)就有出現(xiàn)干擾的可能廷痘，如何解決沖突就是一個問題蔓涧。在樂觀鎖中當(dāng)你在提交更新請求之前，你要先去檢查你讀取這個數(shù)據(jù)之后該數(shù)據(jù)是否發(fā)生了變化笋额，如果有那么你此次的提交就要放棄元暴，如果沒有就可以提交。
Zookeeper中的版本號就是樂觀鎖兄猩，你修改節(jié)點數(shù)據(jù)之前會讀取這個數(shù)據(jù)并記錄該數(shù)據(jù)版本號茉盏，當(dāng)你需要更新時會攜帶這個版本號去提交，如果你此時攜帶的版本號（就是你上次讀取出來的）和當(dāng)前節(jié)點的版本號相同則說明該數(shù)據(jù)沒有被修改過厦滤，那么你的提交就會成功援岩，如果提交失敗說明該數(shù)據(jù)在你讀取之后和提交之前這段時間內(nèi)被修改了。
這里通過set命令并攜帶版本號提交更新掏导，版本號相同更新就會成功享怀。
如果你再次更新并使用之前的版本號那么就會失敗。
10. Zookeeper和Redis區(qū)別
| 區(qū)別點 | Zookeeper | Redis |
|---|---|---|
| 側(cè)重點 | 解決分布式一致性 | 緩存 |
| 存儲量 | 每個znote節(jié)點最多只能存儲1M | Redis則根據(jù)硬盤情況而定 |
| 存儲方式 | String | 五種數(shù)據(jù)類型 |
| 讀寫性能 | 相對比較差 | 優(yōu) |
| 監(jiān)測機制 | Watch,有變動廣而告之 | 無 |
| 數(shù)據(jù)同步 | 集群 + Session | - |
疑問
問題1 客戶端在連接zookeeper的時候,連接的IP地址必須要填寫全部的嗎
測試三臺zookeeper服務(wù)器A,B,C,對應(yīng)的ip為A_ip,B_ip,C_ip
經(jīng)測試發(fā)現(xiàn),
- 1.如果只連接集群中單個A_ip,則這臺A_ip宕機了,客戶端就不能連接到zookeeper集群;
- 2.如果連接多個,不連接全部,只連接了A_ip和B_ip,如果A服務(wù)掛掉(B服務(wù)是ok的),客戶端斷掉后會立馬再次連接,也會連接成功;
連接全部zookeeper服務(wù)ip容錯率好些.
問題2 會不會有同時兩個leader服務(wù)器存在的情況,如果有,怎么處理的;
初始狀態(tài): zookeeper服務(wù)器A,B,C三臺服務(wù)器服務(wù)器中,啟動后A被投為Leader;
當(dāng)A宕機后,B和C重新選擇出B為Leader,當(dāng)A再重新能訪問會發(fā)起新一輪領(lǐng)導(dǎo)選舉,發(fā)現(xiàn)zookeeper集群中的大多數(shù)服務(wù)器(B和C)都選擇了A,那么A也服從大多數(shù),變?yōu)镕ollower;
參考連接:https://mp.weixin.qq.com/s/t2oH5RDw8Ckx3MkciVVnqQ中的4.4:舊Leader恢復(fù)后發(fā)起選舉
解釋
單點故障:（英語：single point of failure趟咆，縮寫SPOF）是指系統(tǒng)中一點失效添瓷，就會讓整個系統(tǒng)無法運作的部件，換句話說值纱，單點故障即會整體故障鳞贷。
參考
https://blog.csdn.net/qq_36660812/article/details/81058358
https://www.cnblogs.com/oxspirt/p/7427969.html
Zookeeper中的Znode特性
https://www.w3cschool.cn/zookeeper/zookeeper_overview.html
https://www.cnblogs.com/aspirant/p/9088322.html
https://mp.weixin.qq.com/s/t2oH5RDw8Ckx3MkciVVnqQ
