zookeeper系統模型之會話清理。當sessiontracker的會話超時檢查執行緒整理出一些已經過期的會話後，那麼就要開始進行會話清理了。會話清理的步驟大致可以分為以下7步。
由於整個會話清理過程需要一段的時間，因此為了保證在此期間不再處理來自該客戶端的新請求，sessiontracker會首先將該會話的isclosing屬性標記為true。這樣，即使在會話清理期間接收到該客戶端的新請求，也無法繼續處理了。
為了使對該會話的關閉操作在整個服務端集群中都生效，zookeeper使用了提交「會話關閉」請求的方式，並立即交付給preprequestprocessor處理器進行處理。
在zookeeper中，一旦某個會話失效後，那麼和該會話相關的臨時（ephemeral）節點都需要被一併清除掉。因此，在清理臨時節點之前，首先需要將伺服器上所有和該會話相關的臨時節點都整理出來。
在zookeeper的記憶體資料庫中，為每個會話都單獨儲存了乙份由該會話維護的所有臨時節點集合，因此在會話清理階段，只需要根據當前即將關閉的會話的sessionid從記憶體資料庫中獲取到這份臨時節點列表即可。
但是，在實際應用場景中，情況並沒有那麼簡單，有如下的細節需要處理：在zookeeper處理會話關閉請求之前，正好有以下兩類請求到達了服務端並正在處理中。
節點刪除請求，刪除的目標節點正好是上述臨時節點中的乙個。臨時節點建立請求，建立的目標節點正好是上述臨時節點中的乙個。對於這兩類請求，其共同點都是事務處理尚未完成，因此還沒有應用到記憶體資料庫中，所以上述獲取到的臨時節點列表在遇上這兩類事務請求的時候，會存在不一致的情況。
假定我們當前獲取的臨時節點列表是ephemerals，那麼針對第一類請求，我們需要將所有這些請求對應的資料節點路徑從ephemerals中移除以避免重複刪除。針對第二類請求，我們需要將所有這些請求對應的資料節點路徑新增到ephemerals中去，以刪除這些即將會被建立但是尚未儲存到記憶體資料庫中去的臨時節點。
完成該會話相關的臨時節點收集後，zookeeper會逐個將這些臨時節點轉換成「節點刪除」請求，並放入事務變更佇列outstandingchanges中去。
在上面的步驟中，我們已經收集了所有需要刪除的臨時節點，並建立了對應的「節點刪除」請求，finalrequestprocessor處理器會觸發記憶體資料庫，刪除該會話對應的所有臨時節點。
完成節點刪除後，需要將會話從sessiontracker中移除。主要就是從上面提到的三個資料結構（sessionbyid、sessionswithtimeout和sessionsets）中將該會話移除掉。
最後，從nioservercnxnfactory找到該會話對應的nioservercnxn，將其關閉。
ZooKeeper系統模型之SetData請求
zookeeper系統模型之setdata請求，服務端對於setdata請求的處理，大體可以分4大步驟，分別是請求的預處理 事務處理 事務應用和請求響應，如下圖所示。zookeeper對於每乙個客戶端請求，都會檢查是否是 會話建立 請求。然而對於setdata請求，因為此時已經完成了會話建立，因此按...
ZooKeeper系統模型之會話重連
zookeeper系統模型之會話重連，當客戶端和服務端之間的網路連線斷開時，zookeeper客戶端會自動進行反覆的重連，直到最終成功連線上zookeeper集群中的一台機器。在這種情況下，再次連線上服務端的客戶端有可能會處於以下兩種狀態之一。connected 如果在會話超時時間內重新連線上了zo...
ZooKeeper資料模型
zookeeper中可以建立一些節點，每乙個節點都唯一對應著乙個用斜線分割的絕對路徑，可以稱之為節點路徑。並且可以為節點關聯相應的資料。這些節點構成類似於檔案系統的樹形一樣的層次結構。在zookeeper中，沒有使用相對路徑的節點。除了下面幾種情況，任何unicode字元都可以作為節點路徑的一部分 ...