[[333876]]

本文轉(zhuǎn)載自微信公眾號(hào)「小姐姐味道」，作者小姐姐養(yǎng)的狗。轉(zhuǎn)載本文請(qǐng)聯(lián)系小姐姐味道公眾號(hào)。

我個(gè)人是非常不喜歡這個(gè)組件的，因?yàn)樗拇a虐過我。引入一個(gè)Netty就可以輕易實(shí)現(xiàn)的網(wǎng)絡(luò)功能，非要自己在代碼里摳 NIO，代碼讓人看的云里霧里。

另外，Zookeeper的擴(kuò)容和縮容，也曾經(jīng)讓我的團(tuán)隊(duì)吃過虧，丟了不少數(shù)據(jù)。用不好的東西，對(duì)它印象就不好，所幸它老了，我也很少用它了。

關(guān)于它的客戶端使用問題，看xjjdog這篇文章就可以了。

《ZK客戶端Curator使用詳解》

1. 什么是 ZooKeeper

[[333877]]

ZooKeeper是一個(gè)分布式的協(xié)調(diào)系統(tǒng)，應(yīng)用非常廣泛。它原是 Hadoop 的一個(gè)子項(xiàng)目，目前是 Apache 基金會(huì)的頂級(jí)項(xiàng)目。像我們常用的微服務(wù)框架 SpringCloud、Dubbo 等，就可以采用 Zookeeper 作為它的注冊(cè)中心。

除了作為注冊(cè)中心，它還有非常多的使用場景，包括：命名服務(wù)、分布式協(xié)調(diào)/通知、選舉、分布式鎖、分布式隊(duì)列、負(fù)載均衡、配置服務(wù)等。

既然 ZooKeeper 談到自己是一個(gè)分布式系統(tǒng)，那它就離不開 CAP 理論，

2. 什么是CAP理論

CAP理論，指的是在一個(gè)分布式系統(tǒng)中， Consistency(一致性)、 Availability(可用性)、Partition tolerance(分區(qū)容錯(cuò)性)，三者不可兼得。下面介紹一下這三個(gè)概念：

• 一致性(C)：在分布式系統(tǒng)的不同節(jié)點(diǎn)或者備份中，同一時(shí)刻是否是一樣的值。比如 MySQL 的主從節(jié)點(diǎn)，由于 binlog 復(fù)制存在時(shí)差，可能在從機(jī)上讀到的數(shù)據(jù)和在主機(jī)上的不一致。
• 可用性(A)：在集群中一部分節(jié)點(diǎn)故障后，集群整體是否還能響應(yīng)客戶端的讀寫請(qǐng)求。
• 分區(qū)容忍性(P)：集群的分區(qū)數(shù)量多了，必然會(huì)在一致性和可用性上有一些問題。以實(shí)際效果而言，分區(qū)相當(dāng)于對(duì)通信的時(shí)限要求。系統(tǒng)如果不能在一定時(shí)間內(nèi)達(dá)成數(shù)據(jù)一致性，就意味著發(fā)生了分區(qū)的情況。

分布式系統(tǒng)，因?yàn)镻是必須的，大多會(huì)在C和A之間做出選擇。而 ZooKeeper ，就是一個(gè)傾向于 CP 的，強(qiáng)一致性的分布式系統(tǒng)。

所以我們要記住這一點(diǎn)，ZooKeeper 的一致性特別強(qiáng)，對(duì)于數(shù)據(jù)一致性要求較高的場景，ZooKeeper都可以有它的用武之地。

同時(shí)，我們也應(yīng)該認(rèn)識(shí)到。ZooKeeper 不能保證每次服務(wù)請(qǐng)求的可用性，在極端環(huán)境下，ZooKeeper可能會(huì)丟棄一些請(qǐng)求，消費(fèi)者程序需要重新請(qǐng)求才能獲得結(jié)果。

從官方的架構(gòu)圖就可以看到，不同的客戶端，連接到 ZooKeeper 集群中的不同機(jī)器，所看到的數(shù)據(jù)，都是一致的，這也是它強(qiáng)一致性的由來。

3. ZooKeeper的使用場景

3.1 注冊(cè)、配置中心

像 Spring Cloud、Dubbo 等服務(wù)節(jié)點(diǎn)的信息，比如機(jī)器列表等，一般數(shù)據(jù)集都比較小，但是一致性卻要求非常的高，而且數(shù)據(jù)經(jīng)常會(huì)發(fā)生變動(dòng)，這是非常適合 ZooKeeper 的一種場景。

通過將這樣的信息發(fā)布到 ZooKeeper上，那么這些數(shù)據(jù)一旦有變動(dòng)，應(yīng)用節(jié)點(diǎn)可以獲得獲取數(shù)據(jù)的一致視圖。

3.2 分布式協(xié)調(diào)/通知

ZooKeeper有Watcher注冊(cè)與異步通知機(jī)制，可以在不同的服務(wù)節(jié)點(diǎn)，甚至是不同的系統(tǒng)間進(jìn)行協(xié)調(diào)。這非常像傳統(tǒng)消息隊(duì)列中的 Pub/Sub 機(jī)制，但由于 ZooKeeper的實(shí)時(shí)性，加上數(shù)據(jù)強(qiáng)一致性，使得數(shù)據(jù)的分發(fā)變的非?？煽?。

3.3 選舉

所謂的選舉，就是在眾多的服務(wù)節(jié)點(diǎn)中，選舉出一個(gè)具有最終決定權(quán)的領(lǐng)導(dǎo)，這在服務(wù)集群中，一般稱為Master。比如，一項(xiàng)服務(wù)需要對(duì)外暴露接口，但是要保證這個(gè)服務(wù)的高可用。當(dāng)正在服務(wù)的節(jié)點(diǎn)當(dāng)機(jī)之后，需要采用選舉功能，從備份的機(jī)制中，選擇出一臺(tái)來，繼續(xù)進(jìn)行服務(wù)。剩余的機(jī)器，則稱為這臺(tái)被選舉機(jī)器的備份。

3.4 分布式鎖

分布式鎖，是為了協(xié)調(diào)分布式環(huán)境下的共享資源而設(shè)定的鎖。比如，你有一個(gè)定時(shí)服務(wù)有兩個(gè)節(jié)點(diǎn)，但要求在執(zhí)行時(shí)只有一個(gè)節(jié)點(diǎn)進(jìn)行業(yè)務(wù)邏輯的計(jì)算。這時(shí)候，任務(wù)就變成了共享資源，在獲取任務(wù)的時(shí)候，就可以采用互斥的手段來保證彼此之間的干擾，保證一致性。

3.5 分布式隊(duì)列

ZooKeeper 也可以實(shí)現(xiàn)分布式隊(duì)列，比如對(duì)一批任務(wù)的執(zhí)行，先處理完前面的任務(wù)，再處理后面的任務(wù)。這個(gè)時(shí)候，就可以將任務(wù)信息存放到 ZooKeeper中。

它與消息隊(duì)列的隊(duì)列概念相似，但比較適合小批量的、有嚴(yán)格順序的任務(wù)。

4. 相似組件

ZooKeeper 是基于 ZAB 協(xié)議構(gòu)建的，這個(gè)協(xié)議和 Paxos 協(xié)議有些相似。由于這些協(xié)議太復(fù)雜了，后續(xù)又有了基于 Raft 協(xié)議的 Etcd 和 Consul。ZooKeeper 是基于Java語言開發(fā)的，而后兩者是使用 Golang 開發(fā)的。

Etcd 和 Consul 作為后起之秀，在功能和性能方面要優(yōu)于 ZooKeeper，它們都是 CP 的系統(tǒng)，使用上區(qū)別不大。

在 Java 生態(tài)里，使用 ZooKeeper 更多一些?？紤]到周邊建設(shè)和產(chǎn)品生態(tài)問題，在Java 企業(yè)級(jí)應(yīng)用中， ZooKeeper 的作用還非常大。

End哪一天我再用它，那絕對(duì)只是工作需要，而不是興趣使然。這也證明了我對(duì)它根本就不精通，雖然也買書看了一點(diǎn)點(diǎn)，但千萬不要留言問我相關(guān)技術(shù)問題。

作者簡介：小姐姐味道 (xjjdog)，一個(gè)不允許程序員走彎路的公眾號(hào)。聚焦基礎(chǔ)架構(gòu)和Linux。十年架構(gòu)，日百億流量，與你探討高并發(fā)世界，給你不一樣的味道。我的個(gè)人微信xjjdog0，歡迎添加好友，進(jìn)一步交流。