應用服務器的高可用設計主要基於服務無狀態這一特性，但事實上，業務總
是有狀態：
在電商網站，需要有購物車記錄用戶的購買信息，用戶每次購買請求都是向購物車中增加商品
在社交類網站，需要記錄用戶的當前登錄狀態、最新發布的消息及好友狀態等，用戶每次刷新頁面都需要更新這些信息
Web 應用中將這些多次請求修改使用的上下文對象稱作會話(Session)。單機情況下，Session 可由部署在服務器上的Web 容器( 如Tomcat) 管理。
在使用負載均衡的集羣環境中，由於負載均衡服務器可能會將請求分發到集羣中的任何一臺應用服務器上，所以保證每次請求依然能夠獲得正確的Session比單機時要複雜很多。
集羣環境下,Session 管理主要有以下幾種手段：
1 Session 複製
早期系統使用的一種服務器集羣Session管理機制。應用服務器開啓Web 容器的Session複製功能，在集羣中的幾臺服務器之間同步Session對象，使得每臺服務器上都保存所有用戶的Session信息,這樣任何一臺機器宕機都不會導致 Session 數據丟失，而服務器使用Session時，也只需在本機獲取。
1.1 優點
雖然簡單,從本機讀取Session信息也很快速,但只能使用在集羣規模比較小的情況下
1.2 缺點
當集羣規模較大時,集羣服務器間需要大量的通信進行Session複製,佔用服務器和網絡的大量資源,系統不堪負擔
而且由於所有用戶的Session信息在每臺服務器上都有備份,在大量用戶訪問的情況下,甚至會出現服務器內存不夠Session使用的情況
而大型網站的核心應用集羣就是數千臺服務器,同時在線用戶可達千萬,因此並不適用這種方案
2 Session綁定(黏制sticky)
可利用負載均衡的源地址Hash算法實現。
負載均衡服務器（比如 nginx）總是將來源於同一IP的請求分發到同一臺服務器上(也可以根據Cookie信息將同一個戶的請求總是分發到同一臺服務器上，當然這時負載均衡服務器必須工作在HTTP 協議層)。這樣在整個會話期間，用戶所有的請求都在同一臺服務器上處理，即Session綁定在某臺特定服務器上，保證Session總能在這臺服務器上獲取
利用負載均衡的會話黏滯機制將請求綁定到特定服務器
但是Session綁定的方案顯然不符合我們對系統高可用的需求。
缺點
一旦某臺服務器宕機,那麼該機器上的Session也就不復存在了,用戶請求切換到其他機器後因爲沒有Session而無法完成業務處理
因此雖然大部分負載均衡服務器都提供源地址負載均衡算法,但很少有網站利用這個算法進行Session管理。
3 利用Cookie 記錄Session
早期系統使用C/S架構,一種管理Session的方式是將Session記錄在客戶端,每次請求服務器的時候,將Session放在請求中發送給服務器,服務器處理完請求後再將修改過的Session響應給客戶端
如今的B/S架構,網站沒有客戶端,但是可以利用瀏覽器支持的Cookie記錄Session
3.1 缺點
受Cookie大小限制,能記錄的信息有限
每次請求響應都需要傳輸Cookie,影響性能
如果用戶關閉Cookie,訪問就會不正常
3.2 優點
由於Cookie的
簡單易用
可用性高
支持應用服務器的線性伸縮
而大部分應用需要記錄的Session 信息又比較小
因此事實上，許多網站都或多或少地使用Cookie記錄Session。
4 Session服務器
那麼有沒有可用性高、伸縮性好、性能也不錯，對信息大小又沒有限制的服務器集羣Session管理方案呢?
答案就是Session服務器!利用獨立部署的Session服務器(集羣)統一管理Session,應用服務器每次讀寫Session時,都訪問Session服務器
這種方案事實上是將應服務器的狀態分離,分爲
無狀態的應用服務器
有狀態的Session服務器
然後針對這兩種服務器的不同特性分別設計其架構
對於有狀態的Session服務器,一種比較簡單的方法是利用
分佈式緩存
即使用cacheDB存取session信息，應用服務器接受新請求將session信息保存在redis中，當應用服務器發生故障時，web服務器會遍歷尋找可用節點，分發請求，當應用服務器發現session不在本機內存時，則去redis中查找，如果找到則複製到本機，這樣實現session共享和高可用。
數據庫等
在這些產品的基礎上進行包裝,使其符合Session 的存儲和訪問要求。如果業務場景對Session 管理有比較高的要求，比如利用Session 服務集成單點登錄(SSO)、用戶服務等功能，則需要開發專門的Session服務管理平臺。