事實上，網站總是有狀態的。每一個登錄信息、用戶信息常常被存儲在session內部。而當一個網站被部署在不止一台服務器的時候，就會遇到session同步的問題。事實上即使一個很小的網站，也要至少有兩台服務器互為備份，分單流量是必須得，更重要的是無縫切流量升級。為了保證服務的不間斷又要進行網站的維護升級，切流量是最簡單的。那么如何保證切流量的時候session也會跟着同步過去呢？在集群環境下，大致有以下幾種手段：
一、Session復制
這是一種在早期應用系統中使用較多的服務器session管理方式。應用服務器開啟Web容器的session的復制功能，在集群中的幾台服務器之間同步session對象，這樣一台服務器宕機不會導致session數據丟失。即每一台服務器都持有集群中所有的session，每次訪問僅從本機獲取就可以了。其工作形式如下所示：
從session復制的幾條線就可以看出，這種方式僅適用用小型集群。當服務集群規模很大時，集群服務器間的復制就需要大量的通訊，占用大量網絡資源，甚至會出現內存不夠的情況。
二、Session綁定
Session綁定可以利用負載均衡的源地址Hash算法實現，負載均衡服務器總是將來自同一個IP地址的訪問分發到同一台服務器上。這樣整個會話期間，用戶所有的請求都來自一台服務器，保證了Session總是從這台服務器獲取。其工作形式如下圖所示：
但是這樣的系統顯然不符合我們對系統的需求。如果一台服務器宕機，那么其處理的所有請求Session會話全部丟失，用戶因為切換服務器后沒有Session而導致無法完成業務。
三、利用Cookie記錄Session
這種管理方式將Session記錄在客戶端，每次請求服務器的時候，將Session放在請求中發送給服務器，服務器處理完成后再將修改后的Session響應給客戶端。
利用Cookie記錄當然也有缺點，比如Cookie大小限制，能記錄的信息也有限，因為很多時候我們在Session中儲存的也並非String類型的記錄。每次請求都需要傳輸Cookie，影響性能；另外如果用戶關閉Cookie功能就不能用了。但是這種方式因此高可用性、支持服務器的線性伸縮，許多網站都在使用這種方式。我的學校網站也應用了這種技術。
四、Session服務器
如果有這樣一個服務器，可用性高、伸縮性好、性能也不錯，對信息大小又沒有限制，那它就是Session服務器。利用獨立部署的Session服務器統一管理Session，應用服務器每次讀寫Session時，都訪問Session服務器。其工作形式如下所示：
這種方式實際上是將應用服務器的狀態分離，分為無狀態的應用服務器和有狀態的Session服務器，然后針對這兩種服務器的不同特性分別設計其架構。
對於有狀態的Session服務器，一種比較簡單的方式是利用分布式緩存、數據庫等。