tomcat session cluster

時間 2019-11-15

原文原文鏈接

Session的生命週期

　　之前在學習的時候沒怎麼注意，今天又回過頭來仔細研究研究了一下Session的生命週期。css

　　Session存儲在服務器端，通常爲了防止在服務器的內存中（爲了高速存取），Sessinon在用戶訪問第一次訪問服務器時建立，須要注意只有訪問JSP、Servlet等程序時纔會建立Session，只訪問HTML、IMAGE等靜態資源並不會建立Session，可調用request.getSession(true)強制生成Session。html

　　Session何時失效？前端

　　1. 服務器會把長時間沒有活動的Session從服務器內存中清除，此時Session便失效。Tomcat中Session的默認失效時間爲20分鐘。java

　　2. 調用Session的invalidate方法。linux

　　Session對瀏覽器的要求：nginx

　　雖然Session保存在服務器，對客戶端是透明的，它的正常運行仍然須要客戶端瀏覽器的支持。這是由於Session須要使用Cookie做爲識別標誌。 HTTP協議是無狀態的，Session不能依據HTTP鏈接來判斷是否爲同一客戶，所以服務器向客戶端瀏覽器發送一個名爲JSESSIONID的 Cookie，它的值爲該Session的id（也就是HttpSession.getId()的返回值）。Session依據該Cookie來識別是否爲同一用戶。web

　　該Cookie爲服務器自動生成的，它的maxAge屬性通常爲-1，表示僅當前瀏覽器內有效，而且各瀏覽器窗口間不共享，關閉瀏覽器就會失效。所以同一機器的兩個瀏覽器窗口訪問服務器時，會生成兩個不一樣的Session。可是由瀏覽器窗口內的連接、腳本等打開的新窗口（也就是說不是雙擊桌面瀏覽器圖標等打開的窗口）除外。這類子窗口會共享父窗口的Cookie，所以會共享一個Session。正則表達式

　　注意：新開的瀏覽器窗口會生成新的Session，但子窗口除外。子窗口會共用父窗口的Session。例如，在連接上右擊，在彈出的快捷菜單中選擇"在新窗口中打開"時，子窗口即可以訪問父窗口的Session。apache

若是客戶端瀏覽器將Cookie功能禁用，或者不支持Cookie怎麼辦？例如，絕大多數的手機瀏覽器都不支持Cookie。Java Web提供了另外一種解決方案：URL地址重寫。centos

　　URL地址重寫是對客戶端不支持Cookie的解決方案。URL地址重寫的原理是將該用戶Session的id信息重寫到URL地址中。服務器可以解析重寫後的URL獲取Session的id。這樣即便客戶端不支持Cookie，也可使用Session來記錄用戶狀態。 HttpServletResponse類提供了encodeURL(String url)實現URL地址重寫，該方法會自動判斷客戶端是否支持Cookie。若是客戶端支持Cookie，會將URL原封不動地輸出來。若是客戶端不支持Cookie，則會將用戶Session的id重寫到URL中。

　　注意：TOMCAT判斷客戶端瀏覽器是否支持Cookie的依據是請求中是否含有Cookie。儘管客戶端可能會支持Cookie，可是因爲第一次請求時不會攜帶任何Cookie（由於並沒有任何Cookie能夠攜帶），URL地址重寫後的地址中仍然會帶有jsessionid。當第二次訪問時服務器已經在瀏覽器中寫入Cookie了，所以URL地址重寫後的地址中就不會帶有jsessionid了。

tomcat集羣session共享配置方案

使用tomat自帶的cluster方式實現session共享

1、使用tomcat自帶的cluster方式，多個tomcat間自動實時複製session信息，配置起來比較簡單。但這個方案的效率比較低，在大併發下表現並很差。

1.系統環境

系統：centos6.5 主機：172.16.20.54(tomcat1) 172.16.20.55(tomcat2) 172.16.20.51（nginx） Tomcat：apache-tomcat-7.0.54.tar.gz Jdk: jdk-7u75-linux-x64.tar.gz Nginx: nginx-1.2.7.tar.gz

2.配置tomcat集羣

我這裏採用主機的默認配置文件，這裏不作性能設置的說明，具體調優參數能夠參考tomcat官網。首先在server.xml文件把cluster 集羣功能打開便可。而後在<Engine>上添加集羣節點名。這個非必須設置，我這裏爲了演示效果，因此把集羣節點名添加上去。

3.在web.xml上添加<distributable />

使用distributable元素是告訴servlet/JSP容器，編寫的應用將在分佈式Web容器中部署，由於咱們這裏是用默認的配置文檔，因此咱們應該在webapps下的web.xml文件中添加<distributable />元素。

備註：

全部啓用集羣功能的web應用程序，其xml中都須添加<distributable />才能實現集羣功能。若是某web應用程序沒有本身的web.xml，也能夠經過複製默認的web.xml至其WEB-INF目錄中實現。

全部的tomcat實例主機配置都同樣

4.編寫測試頁面

分別在tomcat1和tomcat2主機上編寫index.jsp文件，將其放在webapps/ROOT下，文件內容以下：

<%@ page language=」java」 %>

<html>

<head><title>TomcatA</title></head>

<body>

<h1><font color=」blue」>TomcatA </font></h1>

<tr>

<td>Session ID</td>

</tr>

</table>

</body>

</html>

<%@ page language=」java」 %>

<html>

<head><title>TomcatB</title></head>

<body>

<h1><font color=」blue」>TomcatA </font></h1>

<tr>

<td>Session ID</td>

</tr>

</table>

</body>

</html>

配置nginx

Nginx不是咱們重點的配置內容，因此我這裏只貼upstream的配置,默認的權重都是1：

upstream test{

server 172.16.20.54:8080;

server 172.16.20.55:8080;

}

6. 測試session id是否一致

使用nginx ip_hash實現tomcat session共享

2、利用nginx的upstream模塊，基於ip hash訪問策略，保證訪問的ip始終被路由到同一個tomcat實例上，這個配置只要在 nginx上作配置便可，tomcat無需配置。但若是應用是某一個局域網大量用戶同時登錄，負載策略會顯得不均衡，且若是tomcat實例出現故障，session將丟失。

1.系統環境

系統：centos6.5

主機：172.16.20.54(tomcat1) 172.16.20.55(tomcat2) 172.16.20.51（nginx）

Tomcat：apache-tomcat-7.0.54.tar.gz

Jdk: jdk-7u75-linux-x64.tar.gz

Nginx: nginx-1.2.7.tar.gz

2.配置nginx反向代理tomcat集羣

upstream test{

server 172.16.20.54:8080;

server 172.16.20.55:8080;

ip_hash;

}

備註：tomcat不用作任何配置，測試腳本仍是和以前的同樣

測試session id是否一致

這實際上會有一個很大的問題就是容錯率不高，並且只要當前的tomcat實例出問題了，nginx不得不從新分配下一個實例，天然你的session id也改變了。生產環境不建議用這個方案。

利用memcached-session-manager實現session共享

3、利用memcached把多個tomcat的session集中管理，前端在利用nginx負載和動靜態資源分離，在兼顧系統水平擴展的同時又能保證較高的性能。

1.系統環境

系統：centos6.5

主機：172.16.20.54(tomcat1) 172.16.20.55(tomcat2) 172.16.20.51（nginx）

Tomcat：apache-tomcat-7.0.54.tar.gz

Jdk: jdk-7u75-linux-x64.tar.gz

Nginx: nginx-1.2.7.tar.gz

jar包：asm-3.2.jar minlog-1.2.jar reflectasm-1.01.jar kryo- 1.04.jar kryo-serializers-0.11.jar memcached-session-manager-1.8.3.jar memcached-session-manager-tc7-1.8.3.jar msm-kryo-serializer-1.8.3.jar spymemcached-2.11.1.jar

2.配置nginx反向代理tomcat集羣

upstream test{

server 172.16.20.54:8080;

server 172.16.20.55:8080;

ip_hash;

}

注：只能指定ip_hash是由於讓主機能根據IP地址到指定的實例上，即便tomcat實例出現故障，也能夠從memcached裏獲取 session的值，因此不存在方案二的問題，實際上我認爲方案三是結合了方案一和二的優勢而設計的，若是你這裏不喜歡使用ip_hash也是能夠的，這取決你的自身業務狀況。

3.配置memcached

Memcached的安裝，這裏略過，能夠查看我以前寫的文章memcached集羣及magent緩存代理服務器搭建。這裏在主機172.16.20.54開啓兩個memcached實例，分別是：

/usr/local/memcached/bin/memcached -d -p 11211 -u memcached -m 256 -c 1024 -P /var/run/memcached/memcached_11211.pid

/usr/local/memcached/bin/memcached -d -p 11212 -u memcached -m 256 -c 1024 -P /var/run/memcached/memcached_11212.pid

Memcached1: 172.16.20.54 11211

Memcached1: 172.16.20.54 11212

4. 配置tomcat

能夠在context.xml或者server.xml上配置集羣文件，我這裏在context.xml上添加memcached-session-manager配置語句：

<Manager className=」de.javakaffee.web.msm.MemcachedBackupSessionManager」

sticky=」false」

memcachedNodes=」n1:172.16.20.54:11211 n2:172.16.20.54:11212″

failoverNodes=」」

requestUriIgnorePattern=」.*\.(png|gif|jpg|css|js|ico)$」

sessionBackupAsync=」false」

sessionBackupTimeout=」500″

transcoderFactoryClass=」de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory」

customConverter=」de.javakaffee.web.msm.serializer.kryo.JodaDateTimeRegistration,de.javakaffee.web.msm.serializer.kryo.WicketSerializerFactory」

sticky=」false」 #非黏性設置，默認爲黏性

memcachedNodes #配置memcached節點

failoverNodes #默認爲空，若是這裏指定memcached冗餘節點的話，sticky必定要爲true，不然會報錯

requestUriIgnorePattern #忽略session的正則表達式

sessionBackupAsync #指定Session是否應該被異步保存到Memcached中。若是被設置爲true，backupThreadCount設置起做用，若是設置false，經過sessionBackupTimeout

sessionBackupTimeout #設置備份一個Session所用的時間，若是操做超過期間那麼保存失敗。此屬性只在sessionBackupAsync=」false」是起做用。默認100毫秒

transcoderFactoryClass #默認爲 de.javakaffee.web.msm.JavaSerializationTranscoderFactory此屬性值是建立序列化和反序列化保存到Memcached中的Session的編碼轉換器的工廠類名。這個指定的類必須實現了 de.javakaffee.web.msm.TranscoderFactory和提供一個無參的構造方法。

customConverter #可選項，自定義轉換器容許您提供應用程序特定類型的自定義序列化。多個自定義轉換器類名稱指定逗號隔開(可選空間逗號後)。轉換器類必須在類路徑中可用的web應用程序（WEB-INF/lib中），在這裏能夠不設置。

具體參考參數請查看：

https://code.google.com/p/memcached-session-manager/wiki/SetupAndConfiguration

5.測試session id是否一致

從圖中能夠看出，session一致，且能夠看出是從memcached1中獲取的。

假如，memcached1出現故障，看下session值會不會自動複製到memcached2中去：

從圖中能夠看出session的值是從memcached2中獲取的，且session值保持一致。

至此：tomcat集羣session共享配置方案配置完成。