ZooKeeper的10大內部原理⑤：服務器的構成

群?、追隨者和觀察者根本上都是服務器，我們在實作服務器時使?的主要抽象概念是請求處理器，請求處理器是對處理流?線上不同階段的抽象，每?個服務器實作了?個請求處理器的序列，我們可以把?個處理器想象成添加到請求處理的?個元素，?條請求經過服務器流?線上所有處理器的處理后被稱為得到完全處理，

注意：請求處理器

ZooKeeper代碼里有?個叫RequestProcessor的接?，這個接?的主要?法是processRequest，它接受?個Request引數，在?條請求處理器的流?線上，對相鄰處理器的請求的處理通常通過佇列現實解耦合，當?個處理器有?條請求需要下?個處理器進?處理時，它將這條請求加?佇列，然后，它將處于等待狀態直到下?個處理器處理完此訊息，

5.1 獨?服務器

Zookeeper中最簡單的流?線是獨?服務器（ZeeKeeperServer類），圖9-6描述了此類服務器的流?線，它包含三種請求處理器：

• PrepRequestProcessor、

• SyncRequestProcessor

• FinalRequestProcessor，
  

                       圖9-6：?個獨立服務器的流?線
  

PrepRequestProcessor接受客戶端的請求并執?這個請求，處理結果則是?成?個事務，我們知道事務是執??個操作的結果，該操作會反映到ZooKeeper的資料樹上，事務資訊將會以頭部記錄和事務記錄的?式添加到Request物件中，同時還要注意，只有改變ZooKeeper狀態的操作才會產?事務，對于讀操作并不會產?任何事務，因此，對于讀請求的Request物件中，事務的成員屬性的引?值則為null，

下?個請求處理器為SyncRequestProcessor，SyncRequestProcessor負責將事務持久化到磁盤上，實際上就是將事務資料按順序追加到事務?志中，并?成快照資料，對于硬碟狀態的更多細節資訊，我們將在下?節進?討論，

下?個處理器也是最后?個為FinalRequestProcessor，如果Request物件包含事務資料，該處理器將會接受對ZooKeeper資料樹的修改，否則，該處理器會從資料樹中讀取資料并回傳給客戶端，

5.2 群?服務器

當我們切換到仲裁模式時，服務器的流?線則有?些變化，?先我們介紹群?的操作流?線（類LeaderZooKeeper），如圖9-7所?，

                                         圖9-7：群首服務器的流?線

第?個處理器同樣是PrepRequestProcessor，?之后的處理器則為ProposalRequestProcessor，該處理器會準備?個提議，并將該提議發送給跟隨者，ProposalRequestProcessor將會把所有請求都轉發給CommitRequestProcessor，?且，對于寫操作請求，還會將請求轉發給SyncRequestProcessor處理器，

SyncRequestProcessor處理器所執?的操作與獨?服務器中的?樣，即持久化事務到磁盤上，執?完之后會觸發AckRequestProcessor處理器，這個處理器是?個簡單請求處理器，它僅僅?成確認訊息并回傳給??，我們之前曾提到過，在仲裁模式下，群?需要收到每個服務器的確認訊息，也包括群???，?AckRequestProcessor處理器就負責這個，

在ProposalRequestProcessor處理器之后的處理器為CommitRequestProcessor，CommitRequestProcessor會將收到?夠多的確認，訊息的提議進?提交，實際上，確認訊息是由Leader類處理的（Leader.processAck（）?法），這個?法會將提交的請求加?到CommitRequestProcessor類中的?個佇列中，這個佇列會由請求處理器執行緒進?處理，

下?個處理器也是最后?個為FinalRequestProcessor處理器，它的作?與獨?服務器?樣，FinalRequestProcessor處理更新型別的請求，并執?讀取請求，在FinalRequestProcessor處理器之前還有?個簡單的請求處理器，這個處理器會從提議串列中洗掉那些待接受的提議，這個處理器的名字叫ToBeAppliedRequestProcessor，待接受請求串列包括那些已經被仲裁法定?數所確認的請求，并等待被執?，群?使?這個串列與追隨者之間進?同步，并將收到確認訊息的請求加?到這個串列中，之后ToBeAppliedRequestProcessor處理器就會在FinalRequestProcessor處理器執?后洗掉這個串列中的元素，

注意，只有更新請求才會加?到待接受請求串列中，然后由ToBeAppliedRequest-Processor處理器從該串列移除，

ToBeAppliedRequestProcessor處理器并不會對讀取請求進?任何額外的處理操作，?是由FinalRequestProcessor處理器進?操作，

5.3 追隨者和觀察者服務器

現在我們來討論追隨者（FollowerRequestProcessor類），圖9-8展?了?個追隨者服務器中會?到的請求處理器，我們注意到圖中并不是?個單?序列的處理器，?且輸?也有不同形式：

• 客戶端請求、
• 提議、
• 提交事務，

我們通過箭頭來將標識追隨者處理的不同路徑，

                                                 圖9-8：追隨者服務器的流?線

我們?先從FollowerRequestProcessor處理器開始，該處理器接收并處理客戶端請求，FollowerRequestProcessor處理器之后轉發請求給CommitRequestProcessor，同時也會轉發寫請求到群?服務器，

CommitRequestProcessor會直接轉發讀取請求到FinalRequestProcessor處理器，?且對于寫請求，CommitRequestProcessor在轉發給FinalRequestProcessor處理器之前會等待提交事務，

當群?接收到?個新的寫請求操作時，直接地或通過其他追隨者服務器來?成?個提議，之后轉發到追隨者服務器，當收到?個提議，追隨者服務器會發送這個提議到SyncRequestProcessor處理器，SendRequestProcessor會向群?發送確認訊息，當群?服務器接收到?夠確認訊息來提交這個提議時，群?就會發送提交事務訊息給追隨者（同時也會發送INFORM訊息給觀察者服務器），當接收到提交事務訊息時，追隨者就通過CommitRequestProcessor處理器進?處理，

為了保證執?的順序，CommitRequestProcessor處理器會在收到?個寫請求處理器時暫停后續的請求處理，這就意味著，在?個寫請求之后接收到的任何讀取請求都將被阻塞，直到讀取請求轉給CommitRequestProcessor處理器，通過等待的?式，請求可以被保證按照接收的順序來被執?，

對于觀察者服務器的請求流?線（ObserverZooKeeperServer類）與追隨者服務器的流?線?常相似，但是因為觀察者服務器不需要確認提議訊息，因此觀察者服務器并不需要發送確認訊息給群?服務器，也不?持久化事務到硬碟，對于觀察者服務器是否需要持久化事務到硬碟，以便加速觀察者服務器的恢復速度，這樣的討論正在進?中，因此對于以后的ZooKeeper版本也會會有這?個功能，