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