tomcat集羣擴展session集中管理，Memcached-session-manager...

tomcat集羣擴展session集中管理，Memcached-session-manager使用總結 * 博客分類： * tomcat集羣 * ha

javatomcatwebhasession manager 最近在研究tomcat作負載均衡的時候如何實現ha，還有就是不採用session複製的方法作集羣。

想到的是將session所有存儲在後端的緩存服務器中。

正好網上有這麼一個工具Memcached-session-manager（後面簡稱msm），因此直接扒下來用了。

地址以下：

http://code.google.com/p/memcached-session-manager/

msm支持 stickty（沾粘會話）和non-sticky（非沾粘會話）兩種集羣方式。

sticky就是前端的loadbanlence能保證每一個用戶的請求都路由到了同一個tomcat上。

non-sticky則每一次請求均可能路由到了不一樣的tomcat中。

至於msm在這兩種方式是怎麼處理的看下圖：

下圖來自javaeye的xxtianxiaxing的博客，我這裏引用一下，原文地址爲http://xxtianxiaxing.iteye.com/blog/1269704

1. sticky

2. non-sticky

用msm的session管理manager替代tomcat自身的standardManager。

能夠配置在虛擬服務器的context標籤中，也能夠在context.xml裏面全局配置。

<!--sticky <Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager" memcachedNodes="n1:localhost:11211" requestUriIgnorePattern=".*\.(ico|png|gif|jpg|css|js)$" transcoderFactoryClass="de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory" copyCollectionsForSerialization="false" <!--下面這個是可選的，本身定義特殊的類註冊到kryo自定義轉換器中，實現序列化-->

customConverter="com.test.serializer.CustomKryoRegistration"

/>

-->

<!--non sticky <Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager" memcachedNodes="n1:localhost:11211" sticky="false" sessionBackupAsync="false" lockingMode="auto" requestUriIgnorePattern=".*\.(ico|png|gif|jpg|css|js)$" transcoderFactoryClass="de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory" /> 上面採用的序列化方式是kryo，根據官方提供的數據，這個的序列化效率是最好的，我下面有一些簡單的測試。 感受kryo的效率主要體如今高併發下面。若是非高併發感受跟java的自帶io差很少。若是不使用kryo進行序列化，採用java默認方式的話，請將transcoderFactoryClass改成：de.javakaffee.web.msm.JavaSerializationTranscoderFactory 另外在使用kryo進行序列話的時候，有時候會報序列話錯誤。我開始就報ConcrrentHashMap這個類不能序列化的錯誤。tomcat在的session的Atrribute使用了這個數據結構來保存。要解決這個問題，須要本身寫一個類，將這些特殊的類註冊進去。而後打個jar包放tomcat的lib下。就ok了。 下面是例子： package com.test.serializer; import java.util.concurrent.ConcurrentHashMap; import com.esotericsoftware.kryo.Kryo; import com.esotericsoftware.kryo.serialize.MapSerializer; import de.javakaffee.web.msm.serializer.kryo.KryoCustomization; public class CustomKryoRegistration implements KryoCustomization { public void customize(Kryo kryo) { kryo.register(ConcurrentHashMap.class, new MapSerializer(kryo)); } } 把這個類打好jar包放tomcat的lib目錄下。而後還須要在context中配置customConverter="com.test.serializer.CustomKryoRegistration"，這樣就OK了。 另外集成kryo序列化的環境須要如下jar包。剛開始googleCode的官方網站上沒寫。搞了半天，後來提醒原做者加上了： kryo-serializer: msm-kryo-serializer, kryo-serializers, kryo, minlog, reflectasm, asm-3.2 其餘序列化方式（java自帶的序列化方式外的3方序列化方式）須要的jar： javolution-serializer: msm-javolution-serializer, javolution-5.4.3.1 xstream-serializer: msm-xstream-serializer, xstream, xmlpull, xpp3_min flexjson-serializer: msm-flexjson-serializer, flexjson 能夠查看官方網站的文檔：http://code.google.com/p/memcached-session-manager/wiki/SetupAndConfiguration 搭建好全部環境以後，採用1 nginx(ip_hash)+2 tomcat6.0.35+sticky(最好用6.0.2以上版本，由於新的msm包裏面使用了6.0.2纔有的新方法，否則會報NoSuchMethod-changeSessionId()的錯誤) 驗證是否成功： 登陸發佈的系統（發現這個時候請求所有路由到tomcat1），以後，關閉tomcat1，繼續在裏面作有關session的操做。發現這個時候請求被tomcat2接管，並且session依然保持(從memcached中拿出)。ok，這樣就說明成功了。 non_sticky的配置同樣按上面的方法來驗證是否成功。 *********最後是我在搭建好msm環境後作的一些簡單測試：*************** 測試環境：T5870 2.0G cpu,內存2G小本本，win7系統。tomcat，memcache所有裝win7上。啓動一個memcahed服務給了32m內存。tmcat52m內存。 ok，首先是前面沒有負載均衡，單個tomcat的狀況，請求一個sevlet連接，連接就是從session取個值出來的操做。 用apache ab，-C 參數帶上cookie參數模擬有session的請求，100人，共5000次請求是下面的結果： 不用msm: 1000req/s msm-sticky kryo: 850req/s msm-sticky java標準序列化: 830req/s msm-nonsticky kryo : 440/s(50人併發) 430/s(100人併發) msm-nosticky java標準序列化 : 480/s(50人併發) 270/s(100人併發) 在sticky的狀況下，由於在本地有session的狀況下，省略了從memcached取session緩存的狀況，序列化次數很少，所以性能只有大概1/10的損耗。 在non-stikcy的狀況下，集中的每次從memcached取session，性能損失了大概一半。 而能夠看出，在高併發的狀況下，kryo序列化比java標準序列化要好。併發性能大概在java標準序列化一倍以上。並且在搞併發的non-sticky的狀況下，session中的多線程並行操做衝突嚴重。lock不少(固然這個lock模式能夠設置，甚至能夠徹底不要鎖)。這也嚴重下降了速度。 又測試了1臺nginx(ip_hash作負載均衡)+2tomcat的狀況。 由於暫時無法模擬多ip的請求，因此全部請求都只路由到了tomcat1上。採用kryo序列化的策略依然保持了高併發下處理速度不降低的優點。 仍是400多r/s，而java標準序列化仍是要低一半多。