MSM（Memcached-Session-Manager）的介紹

Tomcat利用MSM實現Session共享方案解說

 

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

1	<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模式的響應流程圖：

轉自：http://www.javashuo.com/article/p-fscvfzzu-bq.html