怎樣分析ZooKeeper 集群

這篇文章將為大家詳細講解有關怎樣分析ZooKeeper 集群，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

一、為什么需要集群

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  的人選要進行選舉，不能就一直讓馬果果占著這個位子，村委會聽后也覺得很有道理，于是拉來馬果果一起商量，馬果果肯定不能同意啊，但是無奈馬小云畢竟是首富，很快就通過上下打點讓村委會一致通過了這個建議

但是現在只有兩個辦事處，如果雙方各執一詞，就平票了，所以村委會再次經過商量決定引入第三個辦事處，這個新辦事處的負責人選擇了村里的著名企業家馬小騰，這樣就不會出現平票的情況，具體選舉規則如下：

• 每天三個辦事處開張前必須要先投票選出一個 Leader

• Leader 必須是經手處理過事務編號最大的

• 需要各個辦事處半數以上的同意

• 一切以 Leader 為主，讀寫請求遵守之前馬果果的定下的流程

• 當 Leader 無法處理事務的時候，需要立即選出新的 Leader，選出之前辦事處不能對外提供服務

所以現在有了三個辦事處成了這樣

關于怎樣分析ZooKeeper 集群就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。