1.    Zookeeper技術內幕

1.1. 會話

1.1.1.  sessionID生成

        4個基本屬性：

        sessionlD：會話ID,用來唯一標識一個會話，每次客戶端建立新會話的時候，ZooKeeper都會為其分配一個全域性唯一的sessionID。

        TimeOut：會話超時間。客戶端在構造ZooKeeper例項的時候，會配置一個 sessionTimeout引數用於指定會話的超時時間。ZooKeeper客戶端向伺服器傳送這個超時時間後，伺服器會根據自己的超時時間限制最終確定會話的超時時間。

        TickTime：下次會話超時時間點。為了便於ZooKeeper對會話實行“分桶策略”管理，同時也是為了高效低耗地實現會話的超時檢測與清理，ZooKeeper會為每個會話標記一個下次會話超時時間點。TickTime是一個13位的long型資料，其值接近於當前時間加上TimeOut，但不完全相等。

        isClosing：該屬性用於標記一個會話是否已經被關閉。通常當服務端檢測到一個會話巳經超時失效的時候，會將該會話的isClosing屬性標記為“已關閉”，這樣就能確保不再處理來自該會話的新請求了。

        SessionTrackerImpl初始化的時候，會呼叫initializeNextSession方法來生成一個初始化的sessionid。

public static long initializeNextSession(long id) {
    long nextSid;
    nextSid = (Time.currentElapsedTime() << 24) >>> 8;
    nextSid =  nextSid | (id <<56);
    return nextSid;
}
 

        上面這個方法就是zookeeper初始化sessionid的演算法，答題分為以下5個步驟：

1.   獲取當前時間的毫秒標識。

我們假設System.currentTimeMillis()取出的值是1380895182327，其64位二進位制表示是：

0000000000000000000000010100000110000011110001000100110111110111

其中明影部分表示高24位，下劃線部分表示低40位。

2.   左移24位

將步驟1中的數值左移24位，得到如下二進位制表示的數值：

0100000110000011110001000100110111110111000000000000000000000000

從上面這個數值中，我們可以看到之前的髙24位已經被移出，同時低24位全部使用0進行了補齊。

3.   無符號右移8位

在將步驟2中的數值無符號右移8位，得到如下二進位制表示的數值：

0000000001000001100000111100010001001101111101110000000000000000

從上面這個數值中，我們可以看到，髙位添加了 8個0。

4.   新增機器標識: SID

在initializeNextSession方法中，出現了一個id變數，該變數就是當前 ZooKeeper伺服器的S1D值。該值通常是一個整數，例如1、2或3,這裡我們為了便於表述，假設該值為2。整數2的64位二進位制表示如下：

0000000000000000000000000000000000000000000000000000000000000010

可以發現其高56位都是0,將其左移56位後，可以得到如下二進位制表示的數值：

0000001000000000000000000000000000000000000000000000000000000000

5.   將步驟3和步驟4得到的兩個64位表示的數值進行“丨”操作

0000000001000001100000111100010001001101111101110000000000000000

|

0000001000000000000000000000000000000000000000000000000000000000

可以得到如下數值:

0000001001000001100000111100010001001101111101110000000000000000

        通過以上的步驟，就完成一個sessionid的初始化，因為ID是一個機器編號，比如1、2或3，因此經過上述演算法計算之後，我們就可以得到一個單機唯一的序列號。高位標識所在的機器，後56位使用當前時間的毫秒數標識進行隨機。

        接下來，我們從幾個演算法細節上再來看看sessionid的初始化演算法。

        為什麼是左移24位？

        以上述步驟1中使用的當前時間為例：

0000000000000000000000010100000110000011110001000100110111110111

        左移24位後是：

0100000110000011110001000100110111110111000000000000000000000000

        我們發現左移24位後，將高位的1移除了，剩下的最高位是0，這樣做的目的就是為了防止負數的出現。如果是左移23位之後，是一個負數，再次基礎上即時進行了右移操作，期數值最高位依然是1，因此之後就無法清晰地從sessionid中分辨出SID的值。

1.1.2.  分桶策略

        Zookeeper採用了一種特殊的會話管理方式，稱之為“分桶策略”，是指將類似的會話放在同一區塊中進行管理，以便於zookeeper對會話進行不同區塊的格里處理以及同一區塊的統一處理，

        在上圖中，我們可以看到，ZooKeeper將所有的會話都分配在了不同的區塊之中，分配的原則是每個會話的“下次超時時間點”（ExpirationTime)。ExpirationTime是指該會話最近一次可能超時的時間點，對於一個新建立的會話而言，其會話建立完畢後， ZooKeeper就會為其計算ExpirationTime，計算方式如下：

                ExpirationTime = CurrentTime + SessionTimeout

        其中CurrentTime指當前時間，單位足毫秒：SessionTimeout指該會話設定的超時時間，單位也是亳秒。那麼上圖中座標所標識的時間，是否就是通過上述公式計算出來的呢？答案是否定的，在ZooKeeper的實際實現中，還做了一個處理。ZooKeeper的Leader伺服器在執行期間會定時地進行會話超時檢査，其時間間隔是ExpirationInterval,單位是毫秒，預設值是tickTime的值，即預設情況下，每隔2000毫秒進行一次會話超時檢查。為了方便對多個會話同時進行超時檢査，完整的ExpirationTime的計算方式如下：

                ExpirationTime_ = CurrentTime + SessionTimeout

                ExpirationTime = (ExpirationTime_ /Expirationlnterval +1)*Expirationlnterval

        也就垃說，上圖中橫座標的ExpirationTime值總是ExpirationInterval的整數倍數。舉個實際例子，假設當前時間的毫秒錶示是1370907000000，客戶端會話設定的超時時間是15000毫秒，ZooKecper伺服器設定的tickTime為2000毫秒，那麼ExpirationInterval 的值同樣為為2000亳秒，於是我們可以計算該會話的ExpirationTime值為1370907016000, 計算過程如下：

                ExpirationTime_ = 1370907000000+15000 = 1370907015000

                ExpirationTime =( 1370907015000/2000 + 1) x 2000 = 137090701600

會話啟用

        為了保持客戶端會話的有效性，在ZooKeeper的執行過程中，客廣端會在會話超時時間過期範圍內向服務端傳送PING請求來保持會話的存效性，我們俗稱“心跳檢測”。同時，服務端需要不斷地接收來自客戶端的這個心跳檢測，並且需要重新啟用對應的客戶端會話，我們將這個重新啟用的過程稱為TouchSession。會話啟用的過程，不僅能夠使服務端檢測到對應客戶端的存活性，同時也能讓客戶端自己保持連線狀態。其主要流程如下圖所示。

        重新計算超時時間之後，將改會話從老的區塊中取出，放到新的超時時間對應的新區塊中，

        通過以上的步驟，就基本完成會話啟用的過程。在上面的會話啟用過程中，我們可以看到，只要客戶端發來心跳檢測，那麼服務端就會進行一次會話啟用。心跳檢測由客戶端主動發起，以PING請求的形式向服務端傳送。但實際上，在ZooKeeper服務端的設計中，只要客戶端有請求傳送到服務端，那麼就會觸發一次會話啟用。因此，總的來講，大體會出現以下兩種情況下的會話啟用。

        •只要客戶端向服務端傳送請求，包括讀或寫請求，那麼就會觸發一次會話啟用。

        •如果客戶端發現在sessionTimeout/3時間內尚未和伺服器進行過任何通訊，即沒有向服務端傳送任何請求，那麼就會主動發起一個PING請求，服務端收到該請求 後，就會觸發上述第一種情況下的會話啟用。

會話超時檢查

        在ZooKeeper中，會話超時檢査由SessionTracker負責的。SessionTracker中有一個單獨的執行緒進行會話超時檢査，這裡我們將其稱為“超時檢査執行緒”，其工作機制的核心思路其實非常簡單：逐個依次地對會話桶中剩下的會話進行清理。

        在上圖中，我們可以看到，如果一個會話被啟用，那麼ZooKeeper會將其從上一個會話桶遷移到下一個會話桶中，例如圖中的session這個會話，由於觸發了會話啟用，因此ZooKeeper會將其從expirationTimel捕遷移到expirationTime n桶中去。於是， expirationTime 1中留下的所有會話都是尚未被啟用的。因此，超時檢査執行緒的任務就是定時檢查出這個會話桶中所有剩下的未被遷移的會話。

        那麼超時檢查執行緒是如何做到定時檢查的呢？這裡就和ZooKeeper會話的分桶策略緊密聯絡起來了。在會話分桶策略中，我們將Expirationlnterval的倍數作為時間點來分佈會話，因此，超時檢測執行緒只要在這些指定的時間點上進行檢査即可，這樣既提髙了會話檢査的效率，而且由於是批量清理，因此效能非常好——這也是為什麼ZooKeeper要通過分桶策略來管理客戶端會話的主要的原因。因為在實際生產環境中，一個ZooKeeper叢集的客戶端會話數能會非常多，逐個依次檢杳會話的方式會非常耗費時間。