session會話保持原理

1. 什麼是會話保持？

會話保持是負載均衡最多見的問題之一，也是一個相對比較複雜的問題。會話保持有時候又叫作粘滯會話(Sticky Sessions)。會話保持是指在負載均衡器上的一種機制，能夠識別客戶端與服務器之間交互過程的關連性，在做負載均衡的同時還保證一系列相關連的訪問請求會保持分配到一臺服務器上｡

2. 何時須要會話保持？

在討論這個問題前，咱們必須先花點時間弄清楚一些概念：什麼是鏈接（Connection）、什麼是會話（Session），以及這兩者之間的區別。須要特別強調的是，若是咱們僅僅是談論負載均衡，會話和鏈接每每具備相同的含義。

從簡單的角度來看，若是用戶須要登陸，那麼就能夠簡單的理解爲會話；若是不須要登陸，那麼就是鏈接。

對於同一個鏈接中的數據包，負載均衡會將其進行NAT轉換後，轉發至後端固定的服務器進行處理。負載均衡系統內部會專門有一張表來記錄這些鏈接的情況，包括：[源IP：端口]、[目的IP：端口]、[服務器IP：端口]、空閒超時時間（Idle Timeout）等等。因爲負載均衡內部記錄鏈接狀態的這張表須要消耗系統的內存資源，所以這張表不可能無限大，全部傳統廠商都會有必定的限制。這張表的大小通常稱之爲最大併發鏈接數，也就是系統同時可以容納的鏈接數量。負載均衡的當前鏈接狀態表項中，設計了一個空閒超時時間（Idle Timeout）的參數。當該鏈接在Idle Timeout內無流量經過時，負載均衡會自動刪除該鏈接條目，釋放系統資源。

刪除鏈接後，客戶端的請求將沒法保證繼續發往同一個後端服務器，須要遵循負載均衡器的流量分發策略。

在某些要求登陸狀態的情境下，要求客戶端和服務器之間保持一個會話（session）以記錄客戶端的各類信息。好比在大多數電子商務的應用系統或者須要進行用戶身份認證的在線系統中，一個客戶與服務器常常通過好幾回的交互過程才能完成一筆交易或者是一個請求的完成。因爲這幾回交互過程是密切相關的，服務器在進行這些交互過程的某一個交互步驟時每每須要瞭解上一次或上幾回的交互過程處理結果，這就要求全部這些相關的交互過程都由一臺服務器完成，而不能被負載均衡器分散到不一樣的服務器上｡不然可能出現異常情景：

• 客戶端輸入了正確的用戶名和口令，但卻反覆跳到登陸頁面；
• 用戶輸入了正確的驗證碼，可是總提示驗證碼錯誤；
• 客戶端放入購物車的物品丟失
• …

所以會話保持機制的意義就在於，確保在合適的情境下，未來自相同客戶端的請求轉發至後端相同的服務器進行處理。換句話說，就是將客戶端與服務器之間創建的多個鏈接，都發送到相同的服務器進行處理。若是在客戶端和服務器之間部署了負載均衡設備，頗有可能這多個鏈接會被轉發至不一樣的服務器進行處理。若是服務器之間沒有會話信息的同步機制，會致使其餘服務器沒法識別用戶身份，形成用戶在和應用系統發生交互時出現異常。

負載均衡但願未來自客戶端的鏈接、請求均衡的轉發至後端的多臺服務器，以免單臺服務器負載太高；而會話保持機制卻要求將某些請求轉發至同一臺服務器進行處理。所以，在實際的部署環境中，咱們要根據應用環境的特色，選擇適當的會話保持機制。

3. 會話保持的分類

3.1. 簡單會話保持（四層會話保持）

簡單會話保持（也稱做基於源地址的會話保持、基於IP的會話保持）是指負載均衡器在做負載均衡時根據訪問請求的源地址做爲判斷關連會話的依據。對來自同一IP地址的全部訪問請求在做負載均時都會被保持到一臺服務器上去｡

簡單會話保持中一個很重要的參數就是鏈接超時值，負載均衡器會爲每個處於保持狀態中的會話設定一個時間值。若一個會話從上一次完成到下次再來之間的間隔時間小於超時值時，負載均衡器將會將新的鏈接進行會話保持；但若是這個間隔大於該超時值，負載均衡器會將新來的鏈接認爲是新的會話而後進行負載平衡。

簡單會話保持實現簡單，只須要根據數據包三､四層的信息就能夠實現，效率比較高｡

但此種方式存在的問題就在於，當多個客戶端經過代理或地址轉換的方式訪問服務器時，因爲來源地址同樣，請求都被分配到同一臺服務器上，會致使服務器之間的負載嚴重失衡。

另一種狀況是，同一個客戶端產生大量併發，要求分配到多個服務器上處理的同時進行會話保持。這時基於客戶端源地址的會話保持方法也會致使負載均衡失效。

以上狀況出現時，就必需要考慮使用其餘的會話保持方式。

3.2. 存會話（session）的會話保持

此種方式經過多個後端服務器共享session的方式，實現與負載均衡同時的會話保持。主要有如下幾種形式：

1) 數據庫存放

Session信息存儲到數據庫表以實現不一樣應用服務器間Session信息的共享。此種方式適合數據庫訪問量不大的網站。

• 優勢：實現簡單
• 缺點：因爲數據庫服務器相對於應用服務器更難擴展且資源更爲寶貴，在高併發的Web應用中，最大的性能瓶頸一般出如今數據庫服務器。所以若是將 Session存儲到數據庫表，頻繁的數據庫操做會影響業務。

2) 文件系統存放

經過文件系統（好比NFS）來實現各臺服務器間的Session共享。此種方式適合併發量不大的網站。

• 優勢：各臺服務器只須要mount存儲Session的磁盤便可，實現較爲簡單。
• 缺點：NFS對高併發讀寫的性能並不高，在硬盤I/O性能和網絡帶寬上存在較大瓶頸，尤爲是對於Session這樣的小文件的頻繁讀寫操做。

3) Memcached存放

利用Memcached來保存Session數據，直接經過內存的方式讀取。

• 優勢：效率高，在讀寫速度上會比存放在文件系統時快不少，並且多個服務器共用Session也更加方便，將這些服務器都配置成使用同一組memcached服務器就能夠，減小了額外的工做量。
• 缺點：一旦宕機內存中的數據將會丟失，但對Session數據來講並非嚴重的問題。若是網站訪問量太大、Session太多的時候memcached會將不經常使用的部分刪除，可是若是用戶隔離了一段時間以後繼續使用，將會發生讀取失敗的問題。

3.3. 基於cookie的會話保持（七層會話保持）

在基於cookie模式下負載均衡器負責插入cookie，後端服務器無需做出任何修改。當客戶端進行第一次請求時，客戶端的HTTP request（不帶cookie）進入負載均衡器， CLB根據負載平衡算法策略選擇後端一臺服務器，並將請求發送至該服務器；後端服務器的HTTP response（不帶cookie）被髮回給負載均衡器。接下來負載均衡器將向該後端服務器插入cookie並將HTTP response返回到客戶端。

當客戶請求再次發生時，客戶HTTP request（帶有上次負載均衡器插入的cookie）進入CLB，而後CLB讀出cookie裏的會話保持數值，將HTTP request（帶有與上面一樣的cookie）發到指定的服務器，而後後端服務器進行請求回覆；因爲服務器並不寫入cookie，HTTP response將不帶cookie，該HTTP response再次通過進入CLB時，CLB將寫入更新後的會話保持cookie。

騰訊雲CLB的7層會話保持能力，就是基於這樣的cookie插入的方式實現的。