在ZooKeeper源碼解析(7)-請(qǐng)求處理(上)的末尾，我們只是提到主要處理請(qǐng)求的方法是PreRequestProcessor中的pRequest()方法，而并沒(méi)有深入的介紹這個(gè)方法的實(shí)現(xiàn)．
在這篇文章中，我會(huì)介紹創(chuàng)建節(jié)點(diǎn)這種請(qǐng)求的處理過(guò)程．其他的請(qǐng)求，跟它類似，就不一一深入介紹了．
我們先大體看一下pRequest()方法的實(shí)現(xiàn)．
我們可以看到，對(duì)于每個(gè)請(qǐng)求，都會(huì)創(chuàng)建對(duì)應(yīng)的Request對(duì)象，然后通過(guò)pRequest2Txn()方法進(jìn)行調(diào)用．
上面我們貼出了處理CreateRequest的全部代碼．
注釋中基本上已經(jīng)寫的很詳細(xì)了．
這里主要就是總結(jié)一下過(guò)程：
- 驗(yàn)證Session是否有效
- 驗(yàn)證要?jiǎng)?chuàng)建的節(jié)點(diǎn)的路徑是否正確
- 驗(yàn)證客戶端是否有權(quán)限創(chuàng)建節(jié)點(diǎn)
- 創(chuàng)建對(duì)應(yīng)類型的節(jié)點(diǎn)的ChangeRecord，主要有下面幾種類型:
- PERSISTENT
- PERSISTENT_SEQUENTIAL
- EPHEMERAL
- EPHEMERAL_SEQUENTIAL
- 如果要?jiǎng)?chuàng)建SEQUENTIAL類型的節(jié)點(diǎn)，那么先生成一個(gè)順序的路徑名
- 創(chuàng)建一個(gè)代表此次操作的CreateTxn
我們可以看到，上面只是創(chuàng)建了ChangeRecord以及CreateTxn，而并沒(méi)有把它進(jìn)行持久化，或者應(yīng)用到DataTree中．
這是為什么呢？
因?yàn)檫@只是PreRequestProcessor中進(jìn)行的操作，后面還有好幾個(gè)RequestProcessor等著進(jìn)行操作呢．
要將ChangeRecord應(yīng)用到DataTree，我們首先需要Leader根據(jù)Zab算法確定此次操作能夠被多半Follower知道吧．
所以這里才不會(huì)應(yīng)用到DataTree．
另外，上面代碼中的還涉及到了ACL．
ZooKeeper中內(nèi)置了下面幾種ACL permission以及Schema：
經(jīng)過(guò)PreRequestProcessor的處理之后，只是進(jìn)行了第一步的處理，后面還有其他的處理．
我們從LeaderZooKeeperServer的setupRequestProcessor()方法中，可以看到，它設(shè)置了好幾個(gè)RequestProcessor，來(lái)對(duì)請(qǐng)求進(jìn)行一系列的處理．
我們可以看到，LeaderZooKeeperServer就設(shè)置了這么幾個(gè)RequestProcessor:
PreRequestProcessor -> ProposalRequestProcessor -> CommitProcessor -> ToBeAppliedRequestProcessor -> FinalRequestProcessor
其處理過(guò)程如下：
- 對(duì)請(qǐng)求進(jìn)行預(yù)處理
- 通過(guò)Zab算法確定能夠提交
- 如果收到了半數(shù)Follower的同意，則提交Proposal
- 應(yīng)用到DataTree
- 給客戶端一個(gè)回復(fù)
基本上一個(gè)請(qǐng)求的處理就是這樣，其它的我也沒(méi)有細(xì)看，應(yīng)該都差不多．請(qǐng)讀者自行閱讀源碼來(lái)了解其他請(qǐng)求的處理過(guò)程．
