2018-08-21 21:43:00 海淵haiyuan

前言

在運維過程中，只要涉及到集群部署就繞不開負載均衡了，很多負載均衡的業務場景中，會話保持是一個很常見的配置需求，現在各大公有云平臺中也是提供了很好的負載均衡器，這裡針對會話保持的原理進行一下說明，以便在使用負載均衡器的時候，有更深入的理解。

會話保持的概念

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

會話保持的業務需求

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

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

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

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

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

負載均衡希望將來自客戶端的連接、請求均衡的轉發至後端的多臺服務器，以避免單臺服務器負載過高；而會話保持機制卻要求將某些請求轉發至同一臺服務器進行處理。因此，在實際的部署環境中，我們要根據應用環境的特點，選擇適當的會話保持機制。

會話保持的分類

四層會話保持

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

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

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

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

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

以上情況出現時，就必須要考慮使用其他的會話保持方式。

存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會將不常用的部分刪除，但是如果用戶隔離了一段時間之後繼續使用，將會發生讀取失敗的問題。

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

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

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