[[333876]]

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

我個人是非常不喜歡這個組件的，因為它的代碼虐過我。引入一個Netty就可以輕易實現(xiàn)的網(wǎng)絡功能，非要自己在代碼里摳 NIO，代碼讓人看的云里霧里。

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

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

《ZK客戶端Curator使用詳解》

1. 什么是 ZooKeeper

[[333877]]

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

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

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

2. 什么是CAP理論

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

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

分布式系統(tǒng)，因為P是必須的，大多會在C和A之間做出選擇。而 ZooKeeper ，就是一個傾向于 CP 的，強一致性的分布式系統(tǒng)。

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

同時，我們也應該認識到。ZooKeeper 不能保證每次服務請求的可用性，在極端環(huán)境下，ZooKeeper可能會丟棄一些請求，消費者程序需要重新請求才能獲得結果。

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

3. ZooKeeper的使用場景

3.1 注冊、配置中心

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

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

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

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

3.3 選舉

所謂的選舉，就是在眾多的服務節(jié)點中，選舉出一個具有最終決定權的領導，這在服務集群中，一般稱為Master。比如，一項服務需要對外暴露接口，但是要保證這個服務的高可用。當正在服務的節(jié)點當機之后，需要采用選舉功能，從備份的機制中，選擇出一臺來，繼續(xù)進行服務。剩余的機器，則稱為這臺被選舉機器的備份。

3.4 分布式鎖

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

3.5 分布式隊列

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

它與消息隊列的隊列概念相似，但比較適合小批量的、有嚴格順序的任務。

4. 相似組件

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

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

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

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

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