除去那些對容器依賴特別高的方案（如： 基於Tomcat的memcached-session-manager / tomcat-redis-session-manager，基於Jetty的jetty-nosql-memcache / jetty-session-redis ），自己整理了下分佈式/集羣下的session共享方案，以備不時之需。
1、F5 BIG-IP 硬件實現session粘性複製
F5 硬件，可以作爲HTTP負載均衡器使用，可以將用戶IP與Session通過F5進行的綁定，使其Session保持一致性。是直接通過智能交換機實現負載，與系統無關。瞭解不多，簡單說就這麼多。
2、Nginx 的ip_hash特性對訪問IP和服務器進行綁定
當某個ip下的客戶端請求指定（固定，因爲根據IP地址計算出一個hash值，根據hash值來判斷分配給那臺服務器，從而每次該ip請求都分配到指定的服務器）的服務器，這樣就可以保證有狀態請求的狀態的完整性，不至於出現狀態丟失的情況。缺點： ip_hash方案必須保證Nginx是最前端的服務器（接受真實的ip），如果nginx不是最前端的服務器，還存在中間件（中間服務器什麼的），那麼nginx獲取的ip地址就不是真實的ip地址，那麼這個ip_hash就沒有任何意義。
3、將session保存到nosql數據庫中（推薦）
這個方案有很多種方式：1、 使用框架的會話管理工具spring-session ；2、 使用shiro這種自帶session(非httpsession)的權限框架 。
可以存到redis 或者 memcache 中。
先說第一種，它替換了Servlet那一套會話管理，既不依賴容器，又不需要改動代碼，並且是用了spring-data-redis那一套連接池，可以說是最完美的解決方案。
第二種前提你的項目中用到了shiro， 需要重寫shiro的SessionDao將session存入redis來實現session共享，可以自己重寫或者找現成的(shiro-redis)。
4、使用Cookie共享session
Java Web的共用的用戶鑑權機制是採用Session-Cookie技術，實現原理是：用戶登錄時，請求到達服務器，服務器調用通過getSession()方法判斷session是否存在，如果不存在，則新建session，並通過其算法爲session生成一個隨機數作爲sessionId，開發者可在session中儲存一些用戶信息；第二次請求時，如獲取用戶信息，getSession()方法判斷session存在，則取出session，而不是新建，從而從session中獲取到用戶的相關信息。
客戶端請求時，可以將cookie信息儲存於request的head中發送給服務器；
服務器響應時，可以將cookie信息置於response中回傳給客戶端。
此方案可以說是獨闢蹊徑了，將分佈式思想用到了極致。如上文分析所說，session-cookie機制中，session與cookie相互關聯，以cookie做中轉站，用來找到對應的session，其中session存放在服務器。那麼如果將session中的內容存放在cookie中呢，那麼則省略了服務器保存session的過程，後臺只需要根據cookie中約定的標識進行鑑權校驗即可。
此法， 受http協議頭長度限制，cookie中存儲的信息不宜過多 ，同時cookie在瀏覽器可以被看到，不太安全，需要進行加密處理。
至於常用的web容器，tomcat和weblogic都有自己的session共享方案，後面再研究。