大家好，今天來講講zookeeper，其實很早就計劃寫關于它的文章，但是由于各種原因一直推到了今天。

熟悉“編程新說”公眾號的讀者都知道，號主在介紹一個事物時并不會直通通懟出來，zookeeper就是什么什么。

相反會以類比的方式循序漸進、層層展開，本文依然采用這種風格，各位坐穩了，讓我們開啟一段大腦的旅程。

邊界的產生與突破

不覺間孩子已經上小學了，前段時間還參加了一次家長會，那就以學校和開會來說吧，這大家都很熟悉。

如果一個班要想開班會，那隨時開都行，不需要提前安排與通知，因為一個班級從內部看就是一個整體，在班級內，同學之間以及與老師之間都可以隨意交流，沒有任何隔閡與阻礙。

一個班級從外部看就是一個獨立的個體，因為班級與班級之間是完全獨立的，因此一個班級的學生和老師都不會隨便跑到其它班級去。這是因為存在著一個邊界，即班級邊界。

正是這個班級邊界把班級隔開了，邊界之內的事情，如班會，可以隨便開展，因為它和邊界之外的一切都無關。但是一旦涉及到邊界之外，也就是跨邊界，那么問題就產生了。

比如學校要開一個全體班級大會，肯定會提前安排好時間地點，以及各個班級在操場上的排列順序，還要提前進行相應的通知。

為什么一個班的班會可以隨時隨地進行，而全體班級大會就要提前安排與通知呢?就是因為它跨了班級邊界，是一個跨邊界問題。

而且班級與班級之間互相獨立，互相不太熟悉，可能溝通起來也不容易，因此需要提前安排好。

那如何通知呢?可以讓班級之間互相通知，如一班通知二班，二班通知三班等等。也可以由一個獨立于所有班級之外的人，如教務處或學生處的人，來依次通知所有班級。

這兩種通知方法在現實中都有使用，所有沒有絕對的好與壞之分，視情況而定即可。

讀者需要明確這兩種方法代表了處理此類問題的兩種方式，一種是獨立個體之間互相直接交流來解決，一種是需要第三方介入來協調解決。

這里可以得出一個結論，邊界的產生是一種自然現象，而且通常邊界不會被打碎或消失，但是可以通過其它手段讓邊界兩邊的事物進行交流協商，這頂多是算是一種“突破”吧。

計算機相關的邊界產生與突破

上一小節的描述非常簡單，相信所有人都能明白。接著就來說說和計算機相關的邊界。其實有很多，我們就說一兩種吧。

操作系統里面有內核空間和用戶空間，它們之間是有邊界的，但是它們之間依然是可以交流的，因為操作系統的開發者已經做好了交流的方式方法。

每個應用程序通常都是一個進程，由于應用之間通常差別較大，而且還有一些其它方面的考慮，如安全問題，所以進程之間是有邊界的，即進程邊界。

操作系統是按進程分配資源的，因此一個進程內部的線程共享這些資源。由于進程邊界的存在，這些資源不能被別的進程使用。所以進程就像是一個班級。

由于不同進行之間通常不需要交流，就像班級之間通常也不怎么交流一樣，所以默認情況下進程之間無法交流，這與操作系統的內核和用戶空間是不同的。

但總歸有特殊情況吧，如果進程間需要交流怎么辦?那只能由開發人員自己想辦法，如通過Socket，來實現。這種情況在中間件里很常見，如Nginx就涉及多個進程。

因為中間件的開發者一般都是牛X的人，他們能夠搞定。但問題是絕大多數開發人員都是搞業務開發的，他們受能力、時間或金錢限制，往往做不出來生產級別的交流方法。

可是有時候業務人員開發的應用程序的進程之間也是需要交流的，就像要開全體班級大會那樣，我們可以類比著來尋求解決方案。

我們可以讓進程之間直接互相交流，就像班級之間互相通知那樣，這一方面對開發人員要求高且費時費力，另一方面是當進程多了之后，它們之間的直接交流就變成了一張網，會很亂。

為了說明這一點，我們看個簡單示例。假如張三、李四、王五是同事，周五下午下班時互相穿錯了衣服，遺憾的是晚上回到家后才發現。他們都想在第二天，就是周六，換過來。

張三需要去找李四，李四需要去找王五，王五又需要去找張三，假設他們都住的相距較遠，這會是一個頗為復雜的問題。那么如果有20個人都互相穿錯了衣服呢，這將會是一個更加復雜的問題。

可以看出，如果個體之間互相直接交流的話，隨著個體數目的增多，將會變得無比混亂與復雜。比較好的解決方法可能大家都想到了。

那就是約定一個合適的地方，如公司，張三、李四、王五都過去，互相交換完衣服后各自回家。這種方法隨著個體的增多效果會越來越好。

其實這種方法就是全體班級開會時的第二種通知方法，由一個第三方無關人員介入來協調處理，此時這個第三方就是教務處或學生處。

那么對于多個進程之間的互相交流的解決方法也是這樣的，由一個第三方無關進程介入來協調處理，此時這個第三方就是ZooKeeper。

這種方法還有一個好處，就是在一定程度上降低了個體的復雜性與要求，以及由此產生的額外問題。

比如有的班級的班主任脾氣不好或不好說話，沒有其它班級的班主任愿意去通知他，此時由教務處人員去通知，就不會有這個問題。

對于進程來說，降低了對業務開發人員的要求，不需要具備完整的進程間通信相關知識，同時降低了進程本身的復雜度，不需要支持完整的進程間通信，可能只需支持客戶端即可。

這種方式的另一個好處是可以被抽象出來做成一個獨立的中間件供大家使用，ZooKeeper就是這樣的。

所以從本質來說，ZooKeeper就是一個第三方，也稱中間人，它搭建了一個平臺，讓所有其它進程通過它來進行間接的交流。

ZooKeeper的數據模型

計算機其實就是用來處理或存儲數據的，運行在它上面的軟件大都也是如此。zookeeper作為多進程的協調者，肯定是跑不了了。

存儲數據和擺放物品是一樣的，不能隨意亂扔，這樣既占地方，又不好看，也難尋找。所以必須得有一定的層次結構。這就是計算機的專業課數據結構了。

最簡單的數據結構就是數組或鏈表了。它們被稱為線性表，是一維的，具有線性關系，即前后順序，優點是簡單，缺點是功能不夠強大。

然后就是樹了，可以認為它是兩維的，左右是兄弟關系，上下是父子關系，因此具有從屬關系。它是一個功能與復雜度兼顧的結構。現實生活中的各類組織架構大都是樹形的。

再復雜的就是圖了，它是網狀結構，可以認為是多維的，由于任何節點都可以連通，因此它表達一種多邊關系。雖功能強大但也很復雜。現實中的鐵路網和人際關系網大都是網狀的。

當然，這是三大類數據結構，每一類中又可以分為很多種。比如樹就有很多種變體，雖然都叫樹，但有的差別還是很大的。

ZooKeeper選擇了樹作為自己存儲數據的結構，其實它和文件系統也非常相似，如下圖：

談到數據就離不開增、刪、改、查，對應樹來說，增就是添加新的節點到樹中，刪就是從樹中刪除某個節點，改就是修改樹中某個節點上存放的數據，查就是找到樹中某個節點讀取它上面存放的數據。

說白了就是樹形表示的是一種結構，真正的數據是在節點上放著呢，葉子節點或非葉子節點都可以。

ZooKeeper應該具備的能力

我們從最常見的場景入手，從宏觀上了解下zookeeper是如何使用的，以及它應該具備哪些能力。

場景一：

有兩個應用程序進程A和B，A先處理數據，處理完后通知B，B再接著處理。我們應該如何利用zookeeper來完成這個呢?一起來分析一下。

首先，進程A連接上zookeeper，在上面創建一個節點來表示自己的存在，假設節點名稱就叫foo吧。

然后在節點上設置一個數據叫doing，表示自己正在處理數據。過了一會處理完后，把節點上的數據更新為done。

這樣進程A的工作就算完了。可是這怎么去影響到進程B呢?我們知道zookeeper完成的是進程間的間接交流，即進程之間是不碰面的。因此只能借助于這個樹形里的節點。

進程B也要連上zookeeper，然后找到foo節點，看好它上面的數據是否由doing變成了done，如果是自己就開始處理數據，如果否那就繼續等著。

問題是進程B不能自己老盯著foo節點啊，這樣太累了，傷神，況且它還要做其它事情呢。那這個事情應該由誰來做呢?很顯然是zookeeper嘛。

于是進程B就對zookeeper說，你給我盯著foo節點，什么時候變成done了通知我一聲，我就開干了。

因此，zookeeper需要具有盯梢能力和通知其它進程的能力。這在zookeeper中對應一個專業術語，叫Watch。

Watch的作用和用法與上面描述的一樣。就是進程B找到foo節點，在上面放一個Watch就可以了。

這樣zookeeper就知道進程B對foo節點比較關注，于是zookeeper就盯著foo節點，一有風吹草動，馬上通知進程B。

備注：關于Watch有非常多的細節問題，這里就不談了。

需要注意的是，這個Watch是一次性的，即只能使用一次。也就是說，zookeeper通知過進程B之后，Watch就被用掉了，以后就不會再通知了。

如果進程B還需要被通知怎么辦?很簡單，那就在foo節點上再放一個新的Watch即可。如此這般下去，就可以保證一直被通知了。

我想這個Watch之所以被設計成一次性的，就是zookeeper不想讓自己太累。睜著一雙大眼，盯的東西太多太久的話，確實很累。

另外，zookeeper在通知進程B的時候，是可以把foo節點存放的數據一并發送過去的。

細心的朋友可能已經發現，zookeeper可以主動向進程B發通知或推數據，說明zookeeper和進程B之間的連接需要被一直保持。

因為進程B的位置比較隨意，本來就是業務進程嘛。一旦連接斷開，就像斷了線的風箏，zookeeper再也無法找到進程B了。

不過zookeeper的位置是固定的，一旦連接斷掉后，進程B可以再次向zookeeper發起連接請求，如果斷開的時間足夠短的話，進程B應該還可以在zookeeper上找回自己曾經擁有的一切。

這就涉及到了會話，因此zookeeper還要有一定的會話延續能力，方便在斷開時間不長的時候找回原來的會話。

因此zookeeper應該有，監視節點、通知進程、保持長連接，會話延續等這樣的能力。

場景二：

有時為了高可用或高性能，通常會把一個應用程序運行多份。假如運行了四份，那就是四個進程，分別是A、B、C、D。

當一個調用過來時，發現A、B、C、D都可以調，那就根據配置的負載均衡策略選出一個調用即可。

假設D進程所在的機器不幸掉電了，其實就是D掛了，那么此時再來一個調用的話，會發現只有A、B、C可以調，D自動就不存在了。

這其實就是Dubbo功能的一部分，那該如何基于zookeeper實現呢?照例一起分析下吧。

由于zookeeper是基于樹形的數據結構，所以還是要拿節點說事。當進程A啟動時，需要連接上zookeeper，然后創建一個節點來代表自己。

節點名稱和節點上存放的數據可以根據實際情況來定，至少要包括該進程運行的IP和端口信息。進程B、C、D也做同樣的事情。

如果讓進程A、B、C、D的節點都位于同一個父節點下面，這樣當一個調用過來后，只要找到這個父節點，讀出它的所有子節點，就得到了所有可調用的進程信息。

如果某一時刻，進程D掛掉了，那么父節點下面進程D對應的那個節點應該會自動被zookeeper刪除。這在zookeeper里有個專業術語，叫臨時節點(Ephemeral Node)。那么與之對應的自然就是永久節點了。

其實工作過程是這樣的，業務進程啟動后與zookeeper建立連接，然后在zookeeper里創建臨時節點并寫入自己的相關信息。接著通過周期性的心跳和zookeeper保持住連接。

一旦業務進程掛掉，zookeeper將接受不到心跳了，那么在超過一定的時間后，zookeeper將會刪除與之對應的臨時節點，表示這個業務進程不再可用了。

Dubbo的做法是將接口名稱和IP端口信息和我們設置的信息整合成一個類似URL的字符串，然后以這個字符串作為名稱來創建臨時節點。

臨時節點不允許有孩子節點，只有永久節點才可以。

本文內容都非常簡單，很容易理解，所以即使初次接觸zookeeper的朋友，看到這里也算是入門了。

如果想再往深里講的話，全部都是一些細節問題了。

作者是工作超過10年的碼農，現在任架構師。喜歡研究技術，崇尚簡單快樂。追求以通俗易懂的語言解說技術，希望所有的讀者都能看懂并記住。