應用服務器的高可用架構設計最為理想的是服務無狀態，但實際上業務總會有狀態的，以session記錄用戶信息的例子來講，未登入時，服務器沒有記入用戶信息的session訪問網站都是以游客方式訪問的，賬號密碼登入網站后服務器必須要記錄你的用戶信息記住你是登入后的狀態，以該狀態分配給你更多的權限。那么管理session有哪些方法呢？
1.session復制
圖1
session復制是早期企業應用系統使用比較多的一種服務器集群Session管理機制。應用服務器開啟Web容器的的Session復制功能，在集群中的幾台服務器之間同步Session對象，是的每台服務器上都保存所有用戶的Session信息，這樣任何一台機器宕機都不會導致Session數據的丟失，而服務器使用Session時候，也只需要在本機獲取即可。如圖1所示。
這種方案簡單，且從本機讀取session也相當快捷，但有非常明顯的缺陷：只能使用在集群規模比較小的情況下（企業應用系統，使用人數少，相對比較常見這種模式），當集群規模比較大的時候，集群服務器之間需要大量的通信進行Session的復制，占用服務器和網絡的大量資源，系統負擔較大。而且由於用戶的session信息在每台服務器上都有備份，在大量用戶訪問下，可能會出現服務器內存都還不夠session使用的情況。
2.session會話保持（黏滯會話）
會話保持是利用負載均衡的原地址Hash算法實現，負載均衡服務器總是將來源於同一IP的請求分發到同一台服務器上，，也可以根據cookie信息將同一個用戶的請求每次都分發到同一台服務器上，不過這時的負載均衡服務器必須工作在HTTP協議層上。這種會話保持也叫黏滯會話(Sticky Sessions)
在Nginx中配置的會話保持：
upstream bakend {
ip_hash;
server 192.168.0.14:88;
server 192.168.0.15:80;
}
這種方案雖然保證了每個用戶都能准確的拿到自己的session，而且大量用戶訪問也不怕，但是這種會話保持不符合系統高可用的需求。這種方案有着致命的缺陷：一旦某台服務器發生宕機，則該服務器上的所有session信息就會不存在，用戶請求就會切換到其他服務器，而其他服務器因為沒有其對應的session信息導致無法完成相關業務。所以這種方法基本上不會被采納。
3.利用cookie記錄session
早期的企業應用系統使用C/S架構，管理session 的方法就是將session記錄在客戶端，每次請求服務器的時候將session放在請求中發送給服務器，服務器處理過請求后再將修改過的session返回給客戶端。網站雖然沒有客戶端，但是可以利用瀏覽器支持的cookie記錄session。
利用cookie記錄session是存在很多缺點：比如cookie的大小存在限制能記錄的信息不能超過限制；比如每次請求都要傳輸cookie影響性能；比如cookie可被修改或者存在破解的可能，導致cookie不能存重要信息，安全系數不夠。但是由於cookie簡單易用，支持服務器的線性伸縮，而且大部分的session信息相對較小，所以其實很多網站或多或少的都會使用cookie來記錄部分不重要的session信息。
4.session服務器（集群）
目前最理想的服務器集群的session管理應該是session服務器，集成了高可用、伸縮性好、對保存信息大小沒有限制、性能也相對很好。這種統一管理session的方式將應用服務器分離，分為無狀態的應用服務器和有狀態的session服務器。如圖2所示：
圖2
對於session服務器設計簡單方式：
1.利用分布式緩存，數據庫等，在這些產品的基礎上進行包裝，使其符合session的存儲和訪問要求。
2.另一種就是業務場景對session管理有很高的要求的時候需要開發專門的session服務管理平台。