會話保持是負載均衡最常見的問題之一，也是一個相對比較復雜的問題。
會話保持有時候又叫做粘滯會話(Sticky Sessions)。
在介紹會話保持技術之前，我們必須先花點時間弄清楚一些概念：什么是連接（Connection）、什么是會話（Session），以及這二者之間的區別。需要特別強調的是，如果我們僅僅是談論負載均衡，會話和連接往往具有相同的含義。
從簡單的角度來看，
如果用戶需要登錄，那么就可以簡單的理解為會話；
如果不需要登錄，那么就是連接。
實際上，會話保持機制與負載均衡的基本功能是完全矛盾的。負載均衡希望將來自客戶端的連接、請求均衡的轉發至后端的多臺服務器，以避免單臺服務器負載過高；而會話保持機制卻要求將某些請求轉發至同一臺服務器進行處理。因此，在實際的部署環境中，我們要根據應用環境的特點，選擇適當的會話保持機制。
原始負載均衡的基本原理
對于同一個連接中的數據包，負載均衡會將其進行NAT轉換后，轉發至后端固定的服務器進行處理，這是負載均衡最基本、最原始的功能。負載均衡系統內部會專門有一張表來記錄這些連接的狀況，包括：[源IP：端口]、[目的IP：端口]、[服務器IP：端口]、空閑超時時間（Idle Timeout）等等。
由于負載均衡內部記錄連接狀態的這張表需要消耗系統的內存資源，因此，這張表不可能無限大，所有廠家都會有一定的限制。這張表的大小一般稱之為最大并發連接數，也就是系統同時能夠容納的連接數量。考慮到建立這些連接的客戶端或服務器會發生一些異常狀況，導致這些連接不能被正常終結掉，因此，負載均衡的當前連接狀態表項中，設計了一個空閑超時時間的參數。這個參數定義為，當該連接在一定時間內無流量通過時，負載均衡會自動刪除該連接條目，釋放系統資源。
看了這段文字之后，應該就能夠很好的理解為什么負載均衡的硬件設備的發展速度，無法和軟件的發展相比較。因為這個硬件的發展速度，比不上服務器的發展速度….
有了會話之后，使用原始的負載均衡就會有問題，常見的異常場景包括：
1.客戶端輸入了正確的用戶名和口令，但卻反復跳到登錄頁面；
2.用戶輸入了正確的驗證碼，但是總提示驗證碼錯誤；
3.客戶端放入購物籃的物品丟失
4.…
因此，會話保持機制的意義就在于，確保將來自相同客戶端的請求，轉發至后端相同的服務器進行處理。換句話說，就是將客戶端與服務器之間建立的多個連接，都發送到相同的服務器進行處理。如果在客戶端和服務器之間部署了負載均衡設備，很有可能，這多個連接會被轉發至不同的服務器進行處理。如果服務器之間沒有會話信息的同步機制，會導致其他服務器無法識別用戶身份，造成用戶在和應用系統發生交互時出現異常。
在大多數電子商務的應用系統或者需要進行用戶身份認證的在線系統中,一個客戶與服務器經常經過好幾次的交互過程才能完成一筆交易或者是一個請求的完成?由于這幾次交互過程是密切相關的,服務器在進行這些交互過程的某一個交互步驟時,往往需要了解上一次交互過程的處理結果,或者上幾步的交互過程結果,服務器進行下一步操作時需要這就要求所有這些相關的交互過程都由一臺服務器完成,而不能被負載均衡器分散到不同的服務器上?
而這一系列的相關的交互過程可能是由客戶到服務器的一個連接的多次會話完成,也可能是在客戶與服務器之間的多個不同連接里的多次會話完成?不同連接的多次會話,最典型的例子就是基于http的訪問,一個客戶完成一筆交易可能需多次點擊,而一個新的點擊產生的請求,可能會重用上一次點擊建立起來的連接,也可能是一個新建的連接?
會話保持就是指在負載均衡器上有這么一種機制,可以識別做客戶與服務器之間交互過程的關連性,在作負載均衡的同時,還保證一系列相關連的訪問請求會保持分配到一臺服務器上?
簡單會話保持
簡單會話保持也被稱為基于源地址的會話保持，也叫基于IP的會話保持,是指負載均衡器在作負載均衡時是根據訪問請求的源地址作為判斷關連會話的依據?對來自同一IP地址的所有訪問請求在作負載均時都會被保持到一臺服務器上去?在BIGIP設備上可以為“同一IP地址"通過網絡掩碼進行區分,比如可以通過對IP地址 192.168.1.1進行255.255.255.0的網絡掩碼,這樣只要是來自于192.168.1.0/24這個網段的流量BIGIP都可以認為他們是來自于同一個用戶,這樣就將把來自于192.168.1.0/24網段的流量會話保持到特定的一臺服務器上?
簡單會話保持里另外一個很重要的參數就是連接超時值,BIGIP會為每一個進行會話保持的會話設定一個時間值,當一個會話上一次完成到這個會話下次再來之前的間隔如果小于這個超時值,BIGIP將會將新的連接進行會話保持,但如果這個間隔大于該超時值,BIGIP將會將新來的連接認為是新的會話然后進行負載平衡?
注意：會話保持時間和連接保持時間不一樣
簡單會話保持實現起來簡單,只需要根據數據包三?四層的信息就可以實現,效率也比較高?
F5對會話保持的支持
F5 BigIP支持多種的會話保持方法,其中包括:簡單會話保持(源地址會話保持)?HTTP Header的會話保持,基于SSL Session ID的會話保持,I-Rules會話保持以及基于 HTTP cookie的會話保持,此外還有基于SIP ID以及Cache設備的會話保持等,但常用的是簡單會話保持,HTTP Header的會話保持以及 HTTP Cookie會話保持以及基于I-Rules的會話保持?
NginX對簡單會話保持的支持
ip_hash
每個請求按訪問ip的hash結果分配，這樣每個訪客固定訪問一個后端服務器，可以解決session的問題。
例如：
upstream bakend {
ip_hash;
server 192.168.0.14:88;
server 192.168.0.15:80;
}
簡單會話保持存在的問題就在于當多個客戶是通過代理或地址轉換的方式來訪問服務器時,由于都分配到同一臺服務器上,會導致服務器之間的負載嚴重失衡?另外一種情況上客戶機數量很少,但每個客戶機都會產生多個并發訪問,對這些必發訪問也要求通過負載均衡器分配到多個服器上,這時基于客戶端源地址的會話保持方法也會導致負載均衡失效?這個時候，就必須要考慮使用其他的會話保持方式，比如session等。
如果使用硬件作為負載均衡設備，如果遇到一些特殊的情況，需要進行個性化定制，其實是非常有難度和挑戰的，再更加多的時間，其實這是根本走不通的，如果使用軟件，比如Nginx或者Apache，我們可以對它進行一定程度上的訂制，盡可能多的滿足業務要求。
一些其他的會話保持的方法
使用數據庫存放session
Session信息存儲到數據庫表，這樣實現不同應用服務器間Session信息的共享。
1.適合數據庫訪問量不大的網站
優點：實現簡單
缺點：由于數據庫服務器相對于應用服務器更難擴展且資源更為寶貴，在高并發的Web應用中，最大的性能瓶頸通常在于數據庫服務器。因此如果將 Session存儲到數據庫表，頻繁的數據庫操作會影響業務。
使用文件系統存放session
通過文件系統（比如NFS方式）來實現各臺服務器間的Session共享，各臺服務器只需要mount共享服務器的存儲Session的磁盤即可，實現較為簡單。但NFS 對高并發讀寫的性能并不高，在硬盤I/O性能和網絡帶寬上存在較大瓶頸，尤其是對于Session這樣的小文件的頻繁讀寫操作。
適合并發量不大的網站.
基于瀏覽器Cookie的Session共享
此種方案把用戶相關的Session信息存儲到瀏覽器的Cookie中，也稱為客戶端Session。
采用flash Cookie、URL重寫的方式傳遞Session信息的方案也可以歸為此類。
缺點：只能夠存儲字符串、數值等基本類型的數據；Cookie大小存在限制；安全性；帶寬及數據解壓縮、網絡傳輸性能問題。
基于Memcached 存儲Session
利用Memcached來保存Session數據，直接通過內存的方式，效率自然能夠提高不少。 在讀寫速度上會比 files 時快很多，而且在多個服務器需要共用 session 時會比較方便，將這些服務器都配置成使用同一組 memcached 服務器就可以，減少了額外的工作量。
缺點： session 數據都保存在 memory 中，一旦宕機，數據將會丟失。但對 session 數據來說并不是嚴重的問題。如果網站訪問量太大，session太多的時候，memcached會將不常用的部分刪除，但是如果用戶隔離了一段時間之后繼續使用，已經全部亂套了。
Tags: 服務器 數據包 客戶端 技術 記錄
文章來源：