我們在伺服器啟動zookeeper的時候能得知，zk服務端對外預設埠是2181。而客戶端連線到服務端上，其本質其實就是乙個tcp連線（長連線） ，當連線正式建立起來的時候，就開起來該次會話的生命週期了。有了會話之後，後續的請求傳送，回應，心跳檢測等機制都是基於會話來實現的。那對於zk的服務端來說，如何維護管理這些會話，就是本文要聊的內容啦~
順便貼一下sessionid生成的原始碼，sessionid的生成和兩個東西相關聯，乙個是時間戳，乙個是機器id
/**其中id是機器id**/
public
static
long
initializenextsession
(long id)
為什麼要如此區分呢？因為zk的服務端會在執行期間定時地對會話進行超時檢測，如果不對session進行維護的話，那在檢測的時候豈不是要遍歷所有的session？這顯然不是乙個好辦法，所以才以超時時間為維度來存放session，這樣在檢測的時候，只需要掃瞄對應的桶就可以了
那這樣的話，新的問題就來了：每個session的超時時間是乙個很分散的值，假設有1000個session，很可能就會有1000個不同的超時時間，進而有1000個桶，這樣有啥意義嗎？這就要回頭看一下expirationtime的計算公式了，再貼一下：
e xp
irat
iont
ime=
curr
entt
ime+
sess
iont
imeo
utexpirationtime_ = currenttime + sessiontimeout
expira
tion
time
=cu
rren
ttim
e+se
ssio
ntim
eout
e xp
irat
iont
ime=
(exp
irat
iont
ime/
expi
rati
onin
terv
al+1
)∗ex
pira
tion
inte
rval
expirationtime = ( expirationtime_/expirationinterval + 1 ) * expirationinterval
expira
tion
time
=(ex
pira
tion
time
/ex
pira
tion
inte
rval
+1)∗
expi
rati
onin
terv
al可以看到，最終得到的expirationtime是expirationinterval的倍數，而expirationinterval就是zk服務端定時檢查過期session的頻率，預設為2000毫秒。所以說，每個session的expirationtime最後都是乙個近似值，是expirationinterval的倍數，這樣的話，zk在進行掃瞄的時候，只需要掃瞄乙個桶即可。
另外讓過期時間是expirationinterval的倍數還有乙個好處就是，讓檢查時間和每個session的過期時間在乙個時間節點上。否則的話就會出現乙個問題：zk檢查完畢的1毫秒後，就有乙個session新過期了，這種情況肯定是不好。
在客戶端與服務端完成連線之後生成過期時間，這個值並不是一直不變的，而是會隨著客戶端與服務端的互動來更新。過期時間的更新，當然就伴隨著session在桶上的遷移
最簡單的一點，客戶端每向服務端傳送請求，包括讀請求和寫請求，都會觸發一次啟用，因為這預示著客戶端處於活躍狀態
而如果客戶端一直沒有讀寫請求，那麼它在timeout的三分之一時間內沒有傳送過請求的話，那麼客戶端會傳送一次ping，來觸發session的啟用。當然，如果客戶端直接斷開連線的話，那麼timeout結束後就會被服務端掃瞄到然後進行清楚了
使用者Session 會話機制
總結 在展開話題之前，先看看乙個普通的分布式站點是咋樣的？1 發生位置 使用者側 例如 瀏覽器 2 實現方式 將使用者資訊 會話資訊 儲存在cookie中，在每次請求時，將這些資訊傳送到server進行解析 一般來說，cookie儲存的會話內容都會進行加密 例如 md5 sha等 這種方式主要依賴於...
ZooKeeper 會話超時
1 會話概述 在zookeeper中，客戶端和服務端建立連線後，會話隨之建立，生成乙個全域性唯一的會話id session id 伺服器和客戶端之間維持的是乙個長連線，在session timeout時間內，伺服器會確定客戶端是否正常連線 客戶端會定時向伺服器傳送heart beat，伺服器重置下次...
ZooKeeper系統模型之會話清理
zookeeper系統模型之會話清理。當sessiontracker的會話超時檢查執行緒整理出一些已經過期的會話後，那麼就要開始進行會話清理了。會話清理的步驟大致可以分為以下7步。由於整個會話清理過程需要一段的時間，因此為了保證在此期間不再處理來自該客戶端的新請求，sessiontracker會首先...