在會話機制一文中，我們對會話的超時檢查機制進行了簡單的說明。主要包括：

• 誰負責進行超時檢查
• 超時檢查的策略是什麼

最後在超時檢查的”會話清理“過程沒有詳細的說明，那麼本文將對這一過程進行詳細的說明。

涉及到的類

• SessionTracker.SessionExpirer，一個介面類
• SessionTrackerImpl中的變數：private final SessionExpirer expirer
• ZooKeeperServer，是SessionExpirer的實現類

會話清理過程

會話清理的工作主要是由實現類ZooKeeperServer中的expire(Session session)方法來完成的。程式碼如下：

public void expire(Session session) {
    long sessionId = session.getSessionId();
    close(sessionId);
}

可以看出整個會話清理的過程由close方法負責執行，該方法的程式碼為：

private void close(long sessionId) {
        Request si = new Request(null, sessionId, 0, OpCode.closeSession, null, null);
        setLocalSessionFlag(si);
        submitRequest(si);
    }
 

可以看出，在ZooKeeper中使用的是提交一個請求的方式來進行會話清理工作的。這個請求會經過RequestProcessor（請求處理器）進行處理。

執行流程如下：

• 找到需要清理的臨時節點。臨時節點的生命週期與會話息息相關，一旦繫結的會話失效，那麼臨時節點也將會被刪除。會話->臨時節點集合，這份資料是維護在ZooKeeper的記憶體資料庫中的。可以根據會話的sessionId獲取到與之相關聯的臨時節點列表。
• 為每個臨時節點建立一個”節點刪除“的請求，每個請求都是一個事務操作，並且放入到事務變更佇列中去
• 由RequestProccessor觸發資料庫操作，刪除會話對應的臨時節點
• 移除會話。主要是從SessionTracker中的sessionsById和sessionsWithTimeout中將會話移除
• 關閉NIOServerCnxn，從NIOServerCnxnFactory中找到對應的NIOServerCnxn，將其關閉。

在上面的過程2中，獲取一份待刪除的臨時節點的列表sets。這在分散式併發環境下，可能會出現問題。比如在處理會話清理的過程中，出現一下情況：

• 刪除sets中的一個節點，出現這種請求
• 建立與該會話相關的節點

上述的兩種請求都是事務操作，事務處理尚未完成，還沒有持久化到資料庫中，因此，在獲取待刪除的臨時節點的時候，就可能會出現不一致的情況。解決辦法：

• 針對第一種情況，將該節點在sets中移除，避免重複刪除
• 針對第二種情況，將該節點add到sets中