http://www.cnblogs.com/leesf456/p/6139266.html
一、前言
前一篇已經(jīng)詳細的講解了Zookeeper的Leader選舉過程，下面接著學習Zookeeper中服務器的各個角色及其細節(jié)。
二、服務器角色
2.1 Leader
Leader服務器是Zookeeper集群工作的核心，其主要工作如下
(1) 事務請求的唯一調(diào)度和處理者，保證集群事務處理的順序性。
(2) 集群內(nèi)部各服務器的調(diào)度者。
1. 請求處理鏈
使用責任鏈來處理每個客戶端的請求時Zookeeper的特色，Leader服務器的請求處理鏈如下
(1) PrepRequestProcessor。請求預處理器。在Zookeeper中，那些會改變服務器狀態(tài)的請求稱為事務請求（創(chuàng)建節(jié)點、更新數(shù)據(jù)、刪除節(jié)點、創(chuàng)建會話等），PrepRequestProcessor能夠識別出當前客戶端請求是否是事務請求。對于事務請求，PrepRequestProcessor處理器會對其進行一系列預處理，如創(chuàng)建請求事務頭、事務體、會話檢查、ACL檢查和版本檢查等。
(2) ProposalRequestProcessor。事務投票處理器。Leader服務器事務處理流程的發(fā)起者，對于非事務性請求，ProposalRequestProcessor會直接將請求轉(zhuǎn)發(fā)到CommitProcessor處理器，不再做任何處理，而對于事務性請求，處理將請求轉(zhuǎn)發(fā)到CommitProcessor外，還會根據(jù)請求類型創(chuàng)建對應的Proposal提議，并發(fā)送給所有的Follower服務器來發(fā)起一次集群內(nèi)的事務投票。同時，ProposalRequestProcessor還會將事務請求交付給SyncRequestProcessor進行事務日志的記錄。
(2) SyncRequestProcessor。事務日志記錄處理器。用來將事務請求記錄到事務日志文件中，同時會觸發(fā)Zookeeper進行數(shù)據(jù)快照。
(3) AckRequestProcessor。負責在SyncRequestProcessor完成事務日志記錄后，向Proposal的投票收集器發(fā)送ACK反饋，以通知投票收集器當前服務器已經(jīng)完成了對該Proposal的事務日志記錄。
(4) CommitProcessor。事務提交處理器。對于非事務請求，該處理器會直接將其交付給下一級處理器處理；對于事務請求，其會等待集群內(nèi)針對Proposal的投票直到該Proposal可被提交，利用CommitProcessor，每個服務器都可以很好地控制對事務請求的順序處理。
(5) ToBeCommitProcessor。該處理器有一個toBeApplied隊列，用來存儲那些已經(jīng)被CommitProcessor處理過的可被提交的Proposal。其會將這些請求交付給FinalRequestProcessor處理器處理，待其處理完后，再將其從toBeApplied隊列中移除。
(6) FinalRequestProcessor。用來進行客戶端請求返回之前的操作，包括創(chuàng)建客戶端請求的響應，針對事務請求，該處理還會負責將事務應用到內(nèi)存數(shù)據(jù)庫中去。
2. LearnerHandler
為了保證整個集群內(nèi)部的實時通信，同時為了確保可以控制所有的Follower/Observer服務器，Leader服務器會與每個Follower/Observer服務器建立一個TCP長連接。同時也會為每個Follower/Observer服務器創(chuàng)建一個名為LearnerHandler的實體。LearnerHandler是Learner服務器的管理者，主要負責Follower/Observer服務器和Leader服務器之間的一系列網(wǎng)絡通信，包括數(shù)據(jù)同步、請求轉(zhuǎn)發(fā)和Proposal提議的投票等。Leader服務器中保存了所有Follower/Observer對應的LearnerHandler。
2.2 Follower
Follower是Zookeeper集群的跟隨者，其主要工作如下
(1) 處理客戶端非事務性請求（讀取數(shù)據(jù)），轉(zhuǎn)發(fā)事務請求給Leader服務器。
(2) 參與事務請求Proposal的投票。
(3) 參與Leader選舉投票。
Follower也采用了責任鏈模式組裝的請求處理鏈來處理每一個客戶端請求，由于不需要對事務請求的投票處理，因此Follower的請求處理鏈會相對簡單，其處理鏈如下
(1) FollowerRequestProcessor。其用作識別當前請求是否是事務請求，若是，那么Follower就會將該請求轉(zhuǎn)發(fā)給Leader服務器，Leader服務器是在接收到這個事務請求后，就會將其提交到請求處理鏈，按照正常事務請求進行處理。
(2) SendAckRequestProcessor。其承擔了事務日志記錄反饋的角色，在完成事務日志記錄后，會向Leader服務器發(fā)送ACK消息以表明自身完成了事務日志的記錄工作。
2.3 Observer
Observer充當觀察者角色，觀察Zookeeper集群的最新狀態(tài)變化并將這些狀態(tài)同步過來，其對于非事務請求可以進行獨立處理，對于事務請求，則會轉(zhuǎn)發(fā)給Leader服務器進行處理。Observer不會參與任何形式的投票，包括事務請求Proposal的投票和Leader選舉投票。其處理鏈如下
2.4 集群間消息通信
Zookeeper的消息類型大體分為數(shù)據(jù)同步型、服務器初始化型、請求處理型和會話管理型。
(1) 數(shù)據(jù)同步型。指在Learner和Leader服務器進行數(shù)據(jù)同步時，網(wǎng)絡通信所用到的消息，通常有DIFF、TRUNC、SNAP、UPTODATE。
(2) 服務器初始化型。指在整個集群或是某些新機器初始化時，Leader和Learner之間相互通信所使用的消息類型，常見的有OBSERVERINFO、FOLLOWERINFO、LEADERINFO、ACKEPOCH和NEWLEADER五種。
(3) 請求處理型。指在進行清理時，Leader和Learner服務器之間互相通信所使用的消息，常見的有REQUEST、PROPOSAL、ACK、COMMIT、INFORM和SYNC六種。
(4) 會話管理型。指Zookeeper在進行會話管理時和Learner服務器之間互相通信所使用的消息，常見的有PING和REVALIDATE兩種。
三、總結
經(jīng)過本篇博文的講解，明白了服務器的各種角色及其作用，以及集群間如何進行通信。謝謝各位園友的觀看~