zookeeper之服務端會話請求<十三>

在前面api中，簡單介紹了客戶端鏈接zookeeper服務器，客戶端開始建立Zookeeper對象，鏈接狀態就會變成CONNECTING狀態，同時客戶端開始等待服務端返回的建立結果，鏈接成功後，客戶端狀態變爲CONNECTED（下圖顯示api中展現的鏈接狀態）

那麼咱們再來看一看在建立會話的過程當中，服務器都作了些什麼，通常客戶端的狀態介於CONNECTING和CONNECTED之間,在整個生命週期中，固然還有其餘的狀態(下圖是從官網文檔中複製的)，針對客戶端的請求，可能的狀態轉換。若是出現諸如會話超時、權限檢查或是客戶端主動退出程序等狀況，客戶端的狀態就會直接變動爲CLOSE狀態。

zookeeper服務端的處理，大致分爲1.接求接受；2.會話建立；3預處理；4.事務處理；5.事務應用；6.會話響應。而後去去網上偷了一張圖過來（會話建立處理流程示意圖），可讓你們看的更加懂，那篇博客也能夠獲益頗多（http://blog.csdn.net/zdy0_2004/article/details/53616146）

 

 

一·接受請求

    NIOServerCnxn負責從底層I/O中讀出內容（客戶端與服務端的全部通訊都是由NIOServerCnxn負責，維護一個客戶端鏈接），主要處理方法是readConnectRequest

反序列化爲readConnectRequest,使用的是jute，前一篇已經介紹，下面是readConnectRequest的主要屬性

  private int protocolVersion;

  private long lastZxidSeen;

  private int timeOut;

  private long sessionId;

  private byte[] passwd;

 

判斷客戶端ZXID，若是大於服務器的ZXID，那麼這臺服務器將不接受客戶端的"會話建立"的請求，返回的msg，其中有句 client must try another server，倒還沒看到zk api是否有重試其餘服務的😎！

設置超時時間，就是會和zoo.cfg比較。

判斷是否須要從新建立會話，而後就是下一步的事情啦。

二·會話建立

在ZooKeeperServer中的createSession中建立會話，爲客戶端生成集羣惟一的sessionID，激活密碼sessianpasswd

三·預處理

 以後就將請求交給了PrepRequestProcessor，放入LinkedBlockingQueue<Request> submittedRequests中，建立事務請求

  

四·事務處理

將請求交給ProposalRequestProcessor處理器。與提議相關的處理器，從ProposalRequestProcessor開始，請求的處理將會進入三個子處理流程，分別是Sync流程、Proposal流程、Commit流程。

五·事務應用

交付給FinalRequestProcessor處理器。FinalRequestProcessor處理器檢查outstandingChanges隊列中請求的有效性， 事務應用。以前的請求處理僅僅將事務請求記錄到了事務日誌中，而內存數據庫中的狀態還沒有改變，所以，須要將事務變動應用到內存數據庫。

六·會話響應

建立響應ConnectResponse。會話建立成功後的響應，包含了當前客戶端和服務端之間的通訊協議版本號、會話超時時間、sessionID和會話密碼， 序列化ConnectResponse， I/O層發送響應給客戶端。