Session共享有多種解決方法，常用的有四種：
1）客戶端Cookie保存
2）服務器間Session同步
3）使用集群管理Session（如MSM）
4）把Session持久化到數據庫
針對上面Session共享四種方法的詳解：
1）客戶端Cookie保存以cookie加密的方式保存在客戶端.優點是減輕服務器端的壓力，每次session信息被寫在客服端,然后經瀏覽器再次提交到服務器。即使兩次請求在集群中的兩台服務器上完成，也可以到達session共享。
2）將session持久化到數據中這種共享session的方式即將session信息存入數據庫中，其它應用可以從數據庫中查出session信息。目前采用這種方案時所使用的數據庫一般為mysql。 利用數據庫共享 session 的方案有一定的實用性，但也有如下缺點：首先 session 的並發讀寫在數據庫中完成，對 mysql 的性能要求比較高；其次，我們需要額外地實現 session 淘汰(超時)邏輯代碼，即定時從數據庫表中更新和刪除 session 信息，增加了工作量。
3）使用服務器間session同步使用主-從服務器的架構，當用戶在主服務器上登錄后，通過腳本或者守護進程的方式，將session信息傳遞到各個從服務器中，這樣用戶訪問其它的從服務器時，就可以讀到session信息。 缺點：比如速度慢、不穩定等，另外，如果 session 信息傳遞是主->從單向的，會有一些風險，比如主服務器down了，其它服務器無法獲得 session 信息
4）使用集群統一管理Session提供一個集群保存session共享信息.其他應用統統把自己的session信息存放到session集群服務器組。當應用系統需要session信息的時候直接到 session 集群服務器上讀取。目前大多都是使用 Memcache 來對 Session 進行存儲。
以Memcache來實現Session共享的方式目前比較流行的有兩種實現方案：
a）使用Filter方式：此方式使用過濾器的方式重新對httpRequest 對象進行了包裝，並加入memcached客戶端,此方式的優點是：使用簡單，把過濾器配置進去即可，另外比較靈活，因為它是在客戶端實現的，配置比較靈活,而且服務器無關，你可以在任何支持servlet的容器上部署。
b）使用Memcached-Session-Manager，俗稱MSM，是一個用於解決分布式 tomcat 環境下 session 共享的問題的開源解決方案。它的實現原理為以tomcat插件的方式部署在服務器，修改了 servlet 容器代碼中的 session 相關代碼，使其連接 memcached ，在 memcached 中創建和更新session。
MSM為什么要產生？
通常來說，對於一些大型的web2.0的網站，在正式部署時一般是部署在不同故障域的多台應用服務器上，以j2ee應用為例，一般都會部署在tomcat下。假如部署了10台tomcat服務器，那這10台tomcat可能是部署在不同的機器上，然后將應用程序copy到這10台tomcat下，然后啟動所有tomcat。一般來說這樣做的目的是為了達到負載均衡以及避免單點故障，另外也考慮到國內網絡環境的原因，避免跨網絡運營商訪問而導致訪問速度低下的問題，當然不要忘了坐鎮這10台tomcat前端的還有我們的反向代理服務器。比如nginx，這個就是另一個話題了，下面主要講的是，對於這種分布式tomcat環境，如何保證session 的唯一性？？
一般來說，大體的解決方案是通過編寫一段代碼或者通過配置tomcat的filter，將產生的session放到同一個內存數據庫中，事實上這確實可行的。然而這種問題應該有更省事更成熟的解決方案，也就是將要說的Memcached_Session_Manager，簡稱msm，這就是一個用於解決分布式tomcat環境下session共享的問題的開源解決方案。
MSM（即memcached session manager）是一個高可用Tomcat session共享解決方案，除了可以從本機內存快速讀取Session信息(僅針對黏性Session)外，還可使用memcached存取Session，以實現高可用。
對於非黏性Session，memcached直接存儲session。除memcached外，還可以其他緩存組件如memcachedb, membase等。
MSM特性：
. 支持黏性、非黏性Session
. 無單一故障點
. 可處理tomcat故障轉移
. 可處理memcached故障轉移
. 插件式session序列化
. 允許異步保存session，以提升響應速度
. 只有當session有修改時，才會將session寫回memcached
. JMX管理&監控
MSM解決的問題：假設有一個Tomcat集群，使用黏性session，如何應對單點故障問題？
為了應對更多的並發量和可用性，可以不斷的增加Tomcat節點，但是單點故障仍舊會是個問題：
如果使用黏性Session，一個Tomcat故障時，其他Tomcat並不能接管故障Tomcat節點的Session。
解決此問題的思路就是將黏性Session同時保存在Memcached中，如果單個Tomcat發生故障，集群中的其他Tomcat可以從Memcached中得到Session信息。
注意：對於非黏性Session，MSM V1.4.0及以后版本已經支持。
--------------------------------------------------------------------------------------------------------------------------------------------
黏性Session和非粘性Session，一般用於tomcat服務集群，二者的區別是：
1）黏性Session（即sessionsticky，不復制Session會話）：
此模式下同一會話中的請求都被派送到同一個tomcat實例上，這樣就無須在多台服務器之間實現session共享了，這是其好處。
不好的地方就是不能實現failureover（故障切換）了，一但用戶訪問的機器掛掉，那么其session就會丟失。
也就是說當用戶發出第一個request后，負載均衡器動態的把該用戶分配到某個節點，並記錄該節點的路由，以后該用戶的所有request都綁定到這個路由，
用戶只會與該server發生交互，這種策略被稱為粘性session。
這種方式將同一用戶的請求轉發到特定的Tomcat服務器上，避免了集群中Session的復制，缺點是用戶只跟一種的一台服務器通信，如果此服務器down掉，那就廢了。
2）非黏性Session（即sessionreplication，復制Session會話）此模式下同一會話中的請求可以被分配到不同的tomcat實例上進行處理，此時就需要在不
同服務器之間同步、復制session，這樣一來即使一台服務器掛掉了，請求在其它服務器上照樣可以訪問到session信息，其缺
點在於Session復制需要系統資源和網絡開銷。
-------------------------------------------------------------------------------------------------------------------------------------------------
MSM如何工作？
首先談下tomcat故障轉移
msm安裝在tomcat里，tomcat會在本地保留所有會話信息就像StandardManager一樣。此外，一個請求完成后，session會被備份到memcached節點。 當服務同一會話的下一次請求時，tomcat可以在本地找到這個會話數據，同一會話的第二次請求 處理完后，會話數據會更新到memcached節點。 假設處理某個會話的tomcat掛了。 那么下次請求會被路由到另一個tomcat。而這個tomcat沒有在本地保存該會話的數據。因此它會去相應的memcached（根據請求頭中sessionid的后綴，后面配置$CATALINA_HOME/conf/context.xml時，memcachedNodes="n1:localhost:11211,n2:localhost:11212"，就是n1,n2）中查找此次請求的會話數據並保存到本地。 這樣這個tomcat就可以處理此次會話了。當這個tomcat處理完此次會話，它會將更新相應memcached節點存儲的session信息。
如下圖tomcat1故障，路由到tomcat2由負載均衡完成(如nginx)。
再說下memcahced故障轉移
msm也實現了memcached的故障轉移。當一個memcached節點不可用時，session信息就會被轉移到其他memcached節點。 與此同時，sessionid會被修改，一個新的JESESSIONID(響應頭會有Set-Cookie:JESSIONID;XXXXXXXXXXXXX)會被發送 到瀏覽器端。當使用粘性session（sticky session）時，確保你的負載均衡不會給sessionid添加后綴。
SESSIONID的格式
MSM知道Memcached節點列表，這些節點標識會存儲在SESSIONID中，SESSIONID值類似：602F7397FBE4D9932E59A9D0E52FE178-n1 【其中n1為Memcached節點標識】
MSM原理
MSM利用Value（Tomcat 閥）對Request進行跟蹤。Request請求到來時，從memcached加載session，Request請求結束時，將tomcat session更新至memcached，以達到session共享之目的，支持sticky（粘性）和non-sticky（非粘性）模式。需要注意的是使用sticky模式時需要配置jvmroute參數，配置方式如下：
配置$CATALINA_HOME/conf/server.xml
<Engine name="Catalina"defaultHost="localhost"jvmRoute="tomcat2">
注意每台tomcat的jvmroute參數都不能一樣。
Sticky 模式：
tomcat session為主session，memcached為備session。Request請求到來時，從memcached加載備session到tomcat (僅當tomcat jvmroute發生變化時，否則直接取tomcat session)；Request請求結束時，將tomcat session更新至memcached，以達到主備同步之目的。
下面是sticky模式時響應的流程圖：
Non-Sticky模式：
tomcat session為中轉session，memcached1為主session，memcached2為備session。Request請求到來時，從memcached2加載備session到tomcat，（當容器中還是沒有session，則從memcached1加載主session到tomcat，這種情況是只有一個memcached節點，或者有memcached1出錯時），Request請求結束時，將tomcat session更新至主memcached1和備memcached2，並且清除tomcat session，以達到主備同步之目的。
如下是non-sticky模式的響應流程圖：
