http://www.iteye.com/topic/1125301css
咱們都知道對於一些大型的web2.0的網站,在正式部署時通常是部署在不一樣故障域的多臺應用服務器上,以j2ee應用爲例,通常咱們都會部署在tomcat下,假如咱們部署了10臺tomcat服務器,那這10臺tomcat多是部署在不一樣的機器上,而後將應用程序copy到這10臺tomcat下,而後啓動全部tomcat,通常來講這樣作的目的是爲了達到負載均衡以及避免單點故障,另外也考慮到國內網絡環境的緣由,避免跨網絡運營商訪問而致使訪問速度低下的問題,固然不要忘了坐鎮這10臺tomcat前端的還有咱們的反向代理服務器,好比nginx,這個就是另外一個話題了,我今天主要講的是,對於這種分佈式tomcat環境,咱們如何保證session 的惟一性(我假定你知道session是什麼)。這也是在日期公司的一個項目中負責解決的一個問題,固然實際上這並非什麼新的議題,以前就有不少解決方案,可是通常來講的大致的解決方案是本身經過編寫一段代碼或者經過配置tomcat的filter,將產生的session放到同一個內存數據庫中,事實上這確實可行的,只不過我比較懶,我老是以爲這種問題應該有更省事更成熟的解決方案,那確實是有的,也就是我立刻介紹的 Memcached_Session_Manager,簡稱msm,這就是一個用於解決分佈式tomcat環境下session共享的問題的開源解決方案。html
(如下內容由我的根據msm官網大意翻譯,原文地址:http://code.google.com/p/memcached-session-manager/)前端
引言java
MSM--memcached session manager是一個高可用的Tomcat session共享解決方案,除了能夠從本機內存快速讀取Session信息(僅針對黏性Session)外,同時可以使用memcached存取Session,以實現高可用。nginx
對於非黏性Session,memcached直接存儲session。web
除memcached外,還能夠其餘緩存組件如memcachedb, membase等。數據庫
特性瀏覽器
支持Tomcat六、Tomcat7緩存
支持黏性、非黏性Sessiontomcat
無單一故障點
可處理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及之後版本已經支持。
MSM如何工做
【注】如下論述僅針對黏性Session
安裝在Tomcat上的MSM使用本機內存保存session,和StandardManager同樣。另外,當一個請求結束時,session會被送回Memcached進行備份。當下一次請求開始時,本地Session可用,直接服務,請求結束後,session又被送回Memcached備份。
當集羣中的一個Tomcat掛掉,下一次請求會被路由到其餘Tomcat上。負責處理此此請求的Tomcat並不清楚Session的信息。此時它會從Memcached查找該Session,更新該Session並將其保存在本機內容。這次請求結束,session被修改,送回Memcached備份。
.
What else?
上邊介紹的是處理Tomcat故障轉移,MSM又是如何處理Memcached故障轉移呢?
若是一個Memcached故障,當前Memcached中的Session會轉移到其餘Memcached節點,同時,JSESSIONID被修改並送回瀏覽器。
若是使用黏性Session,應確保loadbalancer中配置生成的JSESSIONID無任何後綴。
SESSIONID的格式
MSM知道Memcached節點列表,這些節點標識會存儲在SESSIONID中,SESSIONID值相似:602F7397FBE4D9932E59A9D0E52FE178-n1 【其中n1爲Memcached節點標識】
參考網站:http://code.google.com/p/memcached-session-manager/wiki/SetupAndConfiguration
環境
1. Linux 環境
2. Tomcat7.X (3臺),在同一臺機器上啓動三臺Tomcat須要修改conf/server.xml中的三個端口:8080,8005,8009
3. MemBase (1臺),也可採用memcached,使用方法同樣,只是在java客戶端鏈接時有不一樣。
4. nginx
準備的jar包
注意:不一樣的tomcat版本(tomcat6,tomcat7)所需的包不同,須要針對tomcat版本下載對應的包.
1.這是採用的最新穩定版1.6.1,序列化方式使用的是kryo,注意版本要求與msm版本基本一致,建議統一採用最新穩定版,以下。其中序列化方式是可選的。
2.這是採用的javolution的序列化方式全部須要的包
建議採用kryo序列化方式,效率更高。
配置
1. 將上面所提到的包所有拷貝到tomcat的lib下(三臺tomcat都須要)
2. 修改每臺tomcat的conf目錄下得context.xml文件或者server.xml文件,在其中加入以下任意一段代碼(注意:當使用多臺tomcat時,必定要使用non-sticky模式):
A:使用默認的sticky session,kryo序列化方式,memcached緩存
B:使用non-sticky session
C:使用membase
當使用javolution序列化方式時將:
替換爲:
配置完成後,分別啓動tomcat,正常啓動說明msm配置成功。
3. 最後附上nginx配置:
修改配置文件nginx\conf\nginx.conf
1. 找到內容server {
在它的上面加入以下內容:
2. 找到
把內容更改以下:
3. 找到
把內容改爲以下:
(這是監聽訪問域名綁定那臺服務器80端口的請求)
到這裏全部的配置已經完成,如今準備一個簡單的web工程,並分別部署到三臺tomcat下。啓動memcached(membase),啓動三臺tomcat,啓動nginx,而後在地址欄輸入url地址,看可否成功訪問。關閉其中一臺tomcat,看是否仍然可以正常訪問,可以則說明配置nginx配置成功。
MSM(memcached-session-manager) 支持tomcat6 和tomcat7 ,利用 Value(Tomcat 閥)對Request進行跟蹤。Request請求到來時,從memcached加載session,Request請求結束時,將tomcat session更新至memcached,以達到session共享之目的, 支持 sticky 和 non-sticky 模式。須要注意的是使用sticky模式時須要配置jvmroute參數,配置方式以下:
配置$CATALINA_HOME/conf/server.xml
注意每臺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 爲主 sessionmemcached 2 爲備session。Request請求到來時,從memcached 2加載備 session 到 tomcat,(當 容器 中仍是沒有session 則從memcached1加載主 session 到 tomcat, 這種狀況是隻有一個memcached節點,或者有memcached1 出錯時),Request請求結束時,將tomcat session更新至 主memcached1和備memcached2,而且清除tomcat session 。以達到主備同步之目的,以下是non-sticky模式的響應流程圖:(圖片來源網絡)。