不用程式碼趣講 ZooKeeper 叢集

削微寒發表於2021-03-04

本文作者：HelloGitHub-老荀

Hi，這裡是 HelloGitHub 推出的 HelloZooKeeper 系列，免費開源、有趣、入門級的 ZooKeeper 教程，面向有程式設計基礎的新手。

專案地址：https://github.com/HelloGitHub-Team/HelloZooKeeper

今天開始我們將深入 ZK 叢集相關知識～

一、為什麼需要叢集

1.1 馬果果病了

ZKr～老規矩～

馬果果畢竟年紀大了，這辦事處的事情越來越多，終於有一天扛不住，生病了，住院了，聽醫生說要休息好幾天。辦事處負責人不在的話就不能給村民們提供服務了。大家平時也要注意身體啊～

一連好幾天都沒收到通知的坤坤急死了，還有其他非常依賴辦事處的村民們都一起跑去村委會投訴了，村委會也很無奈啊，最終商量了下，決定請村裡威望同樣很高的著名企業家，太極愛好者並且還是村裡首富的馬小云成立第二辦事處，地點離原來的辦事處也很近，同樣負責處理之前馬果果辦事處的事務。馬小云之前也是辦事處的常客，對其中的流程已經是非常清楚了，一直想為人民做實事的他，欣然答應了下來。

而且已經有了之前的成功經驗，所以直接照搬之前的處理流程就行了。但是細心的村民很快就發現了問題，之前在馬果果的辦事處很多已經記錄過的事務，現在都消失了，在新的辦事處這裡需要重新登記，非常不方便，但是馬小云表示也沒辦法，馬果果病得太突然了，還沒交接過，只能表示讓大家忍忍。

就這樣，過了兩週，馬果果痊癒出院了，在住院期間他也已經得知了馬小云這兩週代他幫助村民解決大小事務，他內心非常感激馬小云所做的一切，熱愛工作的他，第一時間就回到了工作崗位，把辦事處的大門重新開啟，也廣播告訴了村民，自己這裡又能辦理事務了，希望大家可以繼續過來。由於馬小云畢竟業務能力稍差點，處理速度沒那麼快，導致第二辦事處排隊更嚴重了。

聽到第一辦事處又開張的村民們非常高興，畢竟誰也不希望排長隊浪費時間，於是都來到了第一辦事處

但是呢，馬果果休息了兩週，這兩週期間村民的登記的事務，他全部都沒有，村民們紛紛表示這不行啊：“我們不管你們有幾個辦事處，你們得保證資料都是一致的啊！”。村委會也同意村民的訴求，勒令兩個辦事處整改，需要解決這個問題！而且因為馬果果資歷更老，更有經驗，所以讓馬小云一切聽馬果果的指揮，方案也由馬果果去想辦法出臺。

1.2 馬果果的新規定

馬果果不愧薑還是老的辣，很快就想出了一個好辦法，出臺了一系列的規則：

資料必須以馬果果為主
兩個辦事處間需要打通聯絡，隨時保持溝通
之前把村民前來登記的事務區分成讀和寫，是非常正確的決定。之後寫操作必須通過馬果果，讀操作馬小云可以自行解決

但是光出臺規則還不夠，還需要一系列可以落地的操作，於是馬果果向村委會申請，辦事處需要擴招人，村委會決定讓馬果果放手幹，同意了他的申請。

馬果果把自己辦公室的佈置重新調整了下變成了這樣：

簡單介紹下新來的同事們：

小PS負責區分村民的請求是否需要發起提案，並把請求再次轉發給小C以及小S
小C負責管理小PS提案的提交工作，這個職位非常重要，所以馬果果很有私心的請了一個妹子來承擔這個職位
現在的小S不再和小F打交道了而是和小A打交道，等他歸檔完後就會通知小A
因為現在有兩個辦事處了，所以需要聘請一個話務員，專門負責和隔壁的馬小云辦事處進行溝通

光是安排好自己還不夠，馬果果替馬小云也設計了一套新的辦公室方案：

和馬果果不太一樣，這裡也簡單介紹下：

使用小FR替換了原來的小P作為辦事處第一接待人
小S也不和小F打交道了，直接和小SA打交道，等他歸檔完就會通知小SA
和馬果果一樣也聘請了一個話務員負責和馬果果進行聯絡

原來只有馬果果負責的一個辦事處，隨著馬果果的病倒，村民的業務就無法繼續展開了，這就是單點故障，所以在原來的基礎上增加一個辦事處，可以增加整個辦事處的吞吐量的同時也可以在一個辦事處無法提供服務時，不至於導致村民們無法使用，這就是高可用。這也是為什麼需要叢集部署的最重要原因！

二、第一辦事處

引入了叢集前，原本一個節點資料自己內部運作管理就行，非常方便，但是引入叢集后，叢集間的節點如何溝通成了問題，讓我們一起來看看馬果果的新員工們是怎麼做的吧？

不同於之前的單機流程，現在流程複雜了很多，增加了很多出場的人物，為了讓大家能快速記憶，我這裡提前把名字的由來劇透給大家：

小P對應程式碼中的 PrepRequestProcessor 負責預處理
小PS對應程式碼中的 ProposalRequestProcessor 負責寫事務的提案
小C對應程式碼中的 CommitProcessor 負責對事務請求提交
小S對應程式碼中的 SyncRequestProcessor 負責資料的歸檔
小A對應程式碼中的 AckRequestProcessor 負責告訴馬果果當前事務的 ACK 資訊
小F對應程式碼中的 FinalRequestProcessor 負責對記憶體模型的操作

2.1 負責的小PS

原先小P在第一時間詢問村民後，並對當次請求進行標記後，就會把該請求轉發給小PS，小PS做的事情也很簡單：

主要就是看是不是寫請求，如果是的話就要發起提案並且本地要通知小S歸檔。

2.2 忙碌的小C

小C是除了小F最忙碌的人了，她在接受到上一個同事傳遞過來的請求後會：

不是說小C是最忙的嗎？就這？

別急，小C的處理過程的確是比較繁瑣，但是我這裡先給出簡單的流程，最重要的提交操作，我暫時不展開，之後會講～

2.3 小S和小A

小S處理的流程發生了改變，他前面的同事不再是小P，而他處理完歸檔後也不再把請求交給小F而是交給小A，而小A做的事情更簡單，僅僅只是告訴馬果果辦事處此次事務請求歸檔成功，其實就是 ACK。

2.4 話務員

為了更順暢的和隔壁的馬小云辦事處相互溝通，馬果果定下了幾個暗號，而話務員則負責用暗號去通知馬小云

REQUEST
PROPOSAL
ACK
COMMIT

當然暗號不止這些，之後有遇到再說。

在具體展開流程細節前，我覺得還是要把馬小云的流程簡單介紹下，等兩邊都介紹完後，再合併在一起講解～

三、第二辦事處

同樣因為現在有兩個辦事處的關係，馬小云也無法單純使用之前的流程，並且新員工中有明顯區別於馬果果的小FR和小SA，這裡也介紹下：

小FR對應程式碼中的 FollowerRequestProcessor 負責馬小云這邊的預處理
小SA對應程式碼中的 SendAckRequestProcessor 和馬果果的小A類似，通過話務員通知馬果果當前事務的 ACK

3.1 同樣細心的小FR和小SA

和小PS有點類似，也是需要區分讀寫，但區別是寫請求需要通知馬果果。

小SA的邏輯是接受到小S的歸檔資訊後，把 ACK 通知給馬果果，太簡單了就不畫圖了。

四、實戰

剛剛我們把兩個辦事處邏輯都大致介紹了下，但是太過於碎片化了和簡單，所以下面開始進入實戰環節，會分別假定不同的業務場景和複雜程度，從簡單到複雜，把從村民來辦事處登記事務到辦事處處理完成之間的邏輯按照時間順序進行整理。

前排提醒，多圖預警

4.1 一個讀請求（馬果果）

假設我們的坤坤來到馬果果的辦事處，想要查詢雞太美最新的跳舞視訊 /雞太美/跳舞

小P首先知道坤坤是合法的村民，然後詢問得知，此次來辦事處的目的是為了查詢，就會把此次登記標記為讀請求，就把坤坤的請求交給下一個櫃檯的小PS。

小PS拿到請求後，先把請求原封不動的給到了小C，之後通過小P的標記知道了這是一個讀請求，便不做其他處理。

小C取到這個請求後也發現這是一個讀請求，所以也直接交給了小F，自己不需要其他處理。

小F拿出了小紅本檢視，假設 /雞太美/跳舞 存在，把對應的資料就返回給了坤坤。

坤坤拿到了結果心滿意足的回去了並且定好了 17 點的鬧鐘守在電腦前等著雞太美的開播了

可以看到一個讀請求的處理流程是非常簡單的，別急，難度會一點點的增加哦

4.2 一個讀請求（馬小云）

同樣還是我們的坤坤，但是這次來到馬小云的辦事處，同樣想要查詢雞太美最新的跳舞視訊 /雞太美/跳舞

與馬果果不同的是，先處理坤坤請求的是小FR，他會先把請求發給小C，之後通過詢問坤坤得知此次目的是查詢，就不會做其他處理。你可能會問，小FR不需要對坤坤的身份進行核實嗎？我認為可能是因為當前是讀請求所以不會對資料造成破壞，所以並沒有做校驗。

之後的小C和小F和馬果果版本沒有任何不同，就不贅述了。讓我們進入下一個難度吧。

4.3 一個寫請求（馬果果）

寫請求就和讀請求不一樣了，因為根據馬果果的規定，兩個辦事處的資料得保持一致，所以就會涉及到如何通知對方了，讓我們一起來看看吧。

假設我們的坤坤來到馬果果的辦事處，想要為自己建立一個事務登記 /坤坤/日記

小P知道坤坤是合法的村民並且坤坤此次的目的是寫資料，所以就給坤坤的請求打了一個寫事務的標記，就把請求交給了小PS了。

小PS還是先把請求交給了小C先處理。

小C看到此次是寫請求就拿出自己的小本子記了下來

小PS已經得知此次是寫請求。注意！這裡開始就不一樣了，小PS會讓話務員給馬小云辦事處打電話。

話務員告訴他們這次的請求並帶著 PROPOSAL 的暗號。

這裡必須要提一下事務編號，為了嚴格保證村民來登記的順序，馬果果還規定了必須給每一次的寫事務分配一個唯一的遞增數字，從 0 開始。

並且通知馬小云的同時，馬果果也會把當前的提案記錄下來：

這時候我們把視角切換到馬小云這邊，馬小云的話務員接受到馬果果那邊的 PROPOSAL 的暗號後，會直接讓自己這邊的小S進行歸檔，馬小云則會在備忘錄裡記錄：

等小S歸檔完後，就會把坤坤的請求交給小SA

小SA事情很簡單就是讓話務員通知馬果果歸檔完成

接著馬小云這邊的話務員就會給馬果果辦事處打電話通知他們歸檔完成

視角再一次回到馬果果這邊，在小PS讓話務員通知馬小云那邊的同時小S也沒閒著，進行了歸檔的操作

小S歸檔完成後，會把請求交給小A，小A做的事情很簡單就是通知馬果果此次歸檔完成。

我們這裡假設先是馬果果這邊的小S歸檔完成，馬果果在收到歸檔完成訊息後會拿出剛剛的小本本找到對應的提案記錄，並把已經歸檔完成的給記下來：

因為馬果果知道一共有兩個辦事處，所以還需要等待馬小云的歸檔完成通知。

過了一會會，馬小云的歸檔通知也來了，就再在小本本上記下來

至此，兩個辦事處對於當前提案都已經完成了歸檔，馬果果就會讓話務員通知馬小云可以提交了，並且會將小本本上事務 0 的這條記錄刪除（圖就不畫了）。

通知完，馬果果就讓小C可以進行提交了

小C就會拿出剛剛的備忘錄，找到坤坤的等待處理的事務的第一條（當前場景只有一條）就是：建立 /坤坤/日記。就馬上把這個事務交給了小F處理

小F就會在小紅本上把當前事務記錄下來：

交給小F後，小C發現坤坤的所有事務都處理完了，就把他從備忘錄上刪除了：

讓我們把視角再切到馬小云，馬果果這邊的小C在處理的時候，馬小云的話務員收到了來自馬果果的 COMMIT 訊息並告訴了馬小云，而馬小云會從備忘錄中找出最早的一條請求就是：坤坤，建立，/坤坤/日記，然後就會把該請求交給小C

至於之後小C處理以及處理完交給小F處理，和馬果果那邊的邏輯是一樣的，就不贅述了。

至此，一個寫請求（馬果果）的基本流程就算完成了。

4.4 一個寫請求（馬小云）

假設我們的坤坤這次來到馬小云的辦事處，同樣為自己建立一個事務登記 /坤坤/日記

小FR先把請求交給了小C，然後發現了坤坤這次來辦理的是寫請求，就會要求話務員通知馬果果。

話務員就會打電話給馬果果辦事處，並且告訴他們此次的請求以及攜帶上 REQUEST 暗號

而馬小云這邊的小C會和之前的例子一樣，也會在備忘錄裡記錄下

現在我們把視角切到馬果果這邊，話務員接受到 REQUEST 的請求後，告訴了馬果果，而馬果果會直接把這個請求交給小P去處理

彷彿就是坤坤直接來自己辦事處辦理業務一樣，從小P之後的流程和之前的例子可以說是一模一樣了，就不贅述了。

我現在舉了 4 種無併發的場景，除了寫請求都很簡單，我這裡就再把寫請求馬果果重新用圖畫一遍

為了簡約圖中省略了故事中的話務員以及馬果果和馬小云，相同顏色代表處於同一時間處理，時間順序從小到大。

好了，讓我們繼續提升難度進入併發實戰，作為一個公共的辦事處是不可能同時只處理一件事務的！

4.5 多個村民多種請求

這一章節我不會再從頭開始畫圖了，只畫重要的部分，我們先看看，如果有多個村民的話，那幾個小本本是怎麼記的吧！

小C的備忘錄的特點總結：

以村民作為 key，之後的請求是按照請求的順序擺放的佇列
佇列中的第一個請求肯定是寫請求，如果是讀請求的話，就根本不會記錄
當村民對應的請求佇列為空後，整條記錄刪除

我們以圖中的坤坤舉例，假設現在等待的請求是這樣的（我省略了路徑，這裡只關心事務的型別）

當第一個建立的請求入隊後，之後的查詢請求也無法被執行，都需要等到建立請求執行完畢後才能繼續，所以當第一個建立的請求被提交後，之後的查詢1、查詢2、查詢3會被立馬按順序移除出佇列並執行，而查詢4則需要等待前面的刪除和建立全部提交後才會被執行。

這樣的邏輯保證了，同一個客戶端的請求是按照時間順序執行的，不會出現後到的讀請求先於前面的寫請求執行，造成髒讀，但是需要注意的是不同的客戶端的順序是無法保證的，很可能坤坤的建立請求還未提交，之後東東的查詢操作就能被返回了。

馬果果的小本本如果有多條記錄的話就是這樣

你可能會問：雞太美的那條記錄不是歸檔完成了嗎，為什麼還在小本本里？因為 ZK 必須保證事務執行的順序！所以只要有比當前事務編號小的其他事務仍然未提交，本事務就不能提交，圖裡就是雞太美必須等到坤坤和東東都提交完才能進行提交！

馬小云這邊也有一個備忘錄，如果有多條記錄的話會是這樣：

這個備忘錄其實是一個先進先出的佇列，每次馬小云的提交會從佇列中移除最前面的一條記錄來操作。

故事差不多講完了，有些細節用程式設計師的語言再說一下，我其實省略了兩個處理器：

ToBeAppliedRequestProcessor這個處理器在馬果果這邊才是緊接著小C的，但是我個人感覺下來沒什麼用就不講了，大家有興趣可以去了解下
LeaderRequestProcessor 這個處理器才是馬果果的第一個處理器，他的邏輯涉及到會話、ACL，其他就沒什麼用，留到之後有機會講

大家先看下這個圖：

用紅框標記的都是執行緒物件，主要邏輯都在 run 方法中，小P和小S我們之前就講過了，這裡就多了小C和小FR。這裡我得提一下，但凡你們只要在 ZK 中看到執行緒物件，那麼他基本上是使用了生產者-消費者的模型，物件內部維護了一個阻塞佇列，我這次就不畫圖了，因為重要的邏輯之前都已經講了。

畫了這麼多圖，這裡先進行下小結：

馬果果就是我們平時在 ZK 中聽到的 Leader 節點，負責對寫事務請求發起提案並最終決定提交
馬小云對應就是 ZK 中的 Follower，只能獨自處理讀請求，寫請求需要轉發給 Leader 去處理
讀請求無論客戶端請求給哪個服務端的節點，處理流程都相對簡單，可能幾乎不需要節點之間的通訊，自己就能處理（前提是沒有待處理的寫請求）
寫請求如果客戶端請求到的是 Leader， Leader 就會對此次事務請求在叢集中發起提案，接受到提案的 Follower 各自進行歸檔，並返回給 Leader 成功的 ACK 資訊，Leader 對 ACK 進行統計，達到叢集數量半數以上就叢集中發起 COMMIT 請求，Follower 們接收到提交請求後，才會修改各自記憶體中的資料
寫請求如果客戶端請求到的是 Follower，Follower 在本地做簡單記錄後就會把請求轉發給 Leader 去處理，之後和上一條是一樣的情況
分散式事務的理論中是有回滾階段的，當叢集中的節點本地提交失敗後，會通知 Leader 失敗資訊，而 Leader 統計 ACK 之後發現本次事務無法提交就會傳送回滾的請求給各個節點。但是！很遺憾我並沒有在 ZK 的原始碼中找到和事務回滾有關的邏輯（當然也很有可能是我疏忽了，如果你知道邏輯在哪兒的話，請一定告訴我），我現在的認為小S處理歸檔的時候是不允許失敗的，如果失敗報錯了，整個服務節點會報錯退出

五、劇透

在本篇文章的最後，我們再看看動物村又發生了哪些故事吧。

馬果果畢竟年事已高，需要定期去醫院進行體檢，就會耽誤辦事處這邊的工作，而漸漸的隨著時間的推移，馬小云的業務能力越來越強了，心裡就產生了：憑什麼我要聽這老頭的？於是主動向村委會提議，建議 Leader 的人選要進行選舉，不能就一直讓馬果果佔著這個位子，村委會聽後也覺得很有道理，於是拉來馬果果一起商量，馬果果肯定不能同意啊，但是無奈馬小云畢竟是首富，很快就通過上下打點讓村委會一致通過了這個建議