應用伺服器的高可用架構設計最為理想的是服務無狀态，但實際上業務總會有狀态的，以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服務管理平台。