隨著網際網路應用的使用者量不斷激增，併發的需求越來越受到開發者的關注，通過集群的方式來解決web的瓶頸。但是集群的session共享是個比較頭疼的事情，歸結起來就三種解決方案：
（1）客戶端儲存方案：把session加密後存在cookie中,每次session資訊被寫在客服端,然後經瀏覽器再次提交到伺服器.即使兩次請求在集群中的兩台伺服器上完成,也可以到達session共享.這種解決方法的優點是session資訊不用存放在伺服器端,大大減輕了伺服器的壓力.另乙個優點是乙個session中的兩次或多次請求可以在乙個群集中的多個伺服器上完成,可以避免單點故障.目前,**是採用的這種解決方案.
這個方案可能比較陌生，但它在大型**中還是比較普遍被使用。原理是將全站使用者的session資訊加密、序列化後以cookie的方式，統一種植在根網域名稱下（如：.host.com），利用瀏覽器訪問該根網域名稱下的所有二級網域名稱站點時，會傳遞與之網域名稱對應的所有cookie內容的特性，從而實現使用者的cookie化session 在多服務間的共享訪問。
這個方案的優點無需額外的伺服器資源；缺點是由於受http協議頭信心長度的限制，僅能夠儲存小部分的使用者資訊，同時cookie化的 session內容需要進行安全加解密（如：採用des、rsa等進行明文加解密；再由md5、sha-1等演算法進行防偽認證），另外它也會占用一定的頻寬資源，因為瀏覽器會在請求當前網域名稱下任何資源時將本地cookie附加在http頭中傳遞到伺服器。
（2）集中式session共享方案：提供乙個群集儲存session共享資訊.其他應用統統把自己的session資訊存放到session群集伺服器組.當應用系統需要session資訊的時候直接到session群集伺服器上讀取.這種方式具有第一種方式的第二個優點.
（3）session複製方案：配置負載均衡伺服器,讓使用者的乙個session在乙個伺服器完成.定時的備份session資訊到salve上面.一台伺服器down掉後,通過均衡伺服器透明把使用者的請求**到群集中的其他伺服器上,此時需要從salve上讀取備份的session資訊.
還有一種：
2.4 把session持久化到資料庫
介紹說明
這種共享session的方式即將session資訊存入資料庫中，其它應用可以從資料庫中查出session資訊。目前採用這種方案時所使用的資料庫一般為mysql。
利用資料庫共享session的方案有一定的實用性，但也有如下缺點：首先session的併發讀寫在資料庫中完成，對mysql的效能要求比較高；其次，我們需要額外地實現session淘汰邏輯**，即定時從資料庫表中更新和刪除session資訊，增加了工作量
解決java集群的session共享的解決方案
1.客戶端cookie加密。一般用於內網中企業級的系統中，要求使用者瀏覽器端的cookie不能禁用，禁用的話，該方案會失效 2.集群中，各個應用伺服器提供了session複製的功能，tomcat和jboss都實現了這樣的功能。特點 效能隨著伺服器增加急劇下降，容易引起廣播風暴 session資料需要...
tomcat集群session共享
才疏學淺且語無倫次，如有誤人子弟，深表歉意 一台tomcat不夠用時，要麼換更好的機器，要麼加機器做集群。做集群就會涉及到負載均衡，比如nginx，會把到來的每個請求按一定的規則 給後端tomcat，這就有乙個逃避不了的問題需要解決，使用者的session需要在不同的tomcat之間共享。比較偷懶的...
WebSocket 集群 session 共享方案
本文聊天室基於 websocket 進行實現，同時也為解決websocket session在集群部署服務時的無法共享導致的收發訊息問題。當我們使用 websocket 實現聊天時，後端服務會將所有的 websocket session快取起來，之後根據收到的訊息，遍歷或者找到某個session進行...