前言

我們一般在搭建完集群環(huán)境后，不得不考慮的一個問題就是用戶訪問產(chǎn)生的session如何處理。如果不做任何處理的話，用戶將出現(xiàn)頻繁登錄的現(xiàn)象，比如集群中存在A、B兩臺服務(wù)器，用戶在第一次訪問網(wǎng)站時，Nginx通過其負(fù)載均衡機(jī)制將用戶請求轉(zhuǎn)發(fā)到A服務(wù)器，這時A服務(wù)器就會給用戶創(chuàng)建一個Session。當(dāng)用戶第二次發(fā)送請求時，Nginx將其負(fù)載均衡到B服務(wù)器，而這時候B服務(wù)器并不存在Session，所以就會將用戶踢到登錄頁面。這將大大降低用戶體驗度，導(dǎo)致用戶的流失，這種情況是項目絕不應(yīng)該出現(xiàn)的。

我們應(yīng)當(dāng)對產(chǎn)生的Session進(jìn)行處理，通過粘性Session，Session復(fù)制或Session共享等方式保證用戶的體驗度。

以下我將說明5種Session處理策略，并分析其優(yōu)劣性。話不多說了，來一起看看詳細(xì)的介紹吧。

第一種：粘性session

原理：粘性Session是指將用戶鎖定到某一個服務(wù)器上，比如上面說的例子，用戶第一次請求時，負(fù)載均衡器將用戶的請求轉(zhuǎn)發(fā)到了A服務(wù)器上，如果負(fù)載均衡器設(shè)置了粘性Session的話，那么用戶以后的每次請求都會轉(zhuǎn)發(fā)到A服務(wù)器上，相當(dāng)于把用戶和A服務(wù)器粘到了一塊，這就是粘性Session機(jī)制。

優(yōu)點(diǎn)：簡單，不需要對session做任何處理。

缺點(diǎn)：缺乏容錯性，如果當(dāng)前訪問的服務(wù)器發(fā)生故障，用戶被轉(zhuǎn)移到第二個服務(wù)器上時，他的session信息都將失效。

適用場景：發(fā)生故障對客戶產(chǎn)生的影響較小；服務(wù)器發(fā)生故障是低概率事件。

實現(xiàn)方式：以Nginx為例，在upstream模塊配置ip_hash屬性即可實現(xiàn)粘性Session。

upstream mycluster{ #這里添加的是上面啟動好的兩臺Tomcat服務(wù)器 ip_hash;#粘性Session  server 192.168.22.229:8080 weight=1;  server 192.168.22.230:8080 weight=1;}

第二種：服務(wù)器session復(fù)制

原理：任何一個服務(wù)器上的session發(fā)生改變（增刪改），該節(jié)點(diǎn)會把這個 session的所有內(nèi)容序列化，然后廣播給所有其它節(jié)點(diǎn)，不管其他服務(wù)器需不需要session，以此來保證Session同步。

優(yōu)點(diǎn)：可容錯，各個服務(wù)器間session能夠?qū)崟r響應(yīng)。

缺點(diǎn)：會對網(wǎng)絡(luò)負(fù)荷造成一定壓力，如果session量大的話可能會造成網(wǎng)絡(luò)堵塞，拖慢服務(wù)器性能。

實現(xiàn)方式：

① 設(shè)置tomcat ，server.xml 開啟tomcat集群功能

Address:填寫本機(jī)ip即可，設(shè)置端口號，預(yù)防端口沖突。

② 在應(yīng)用里增加信息：通知應(yīng)用當(dāng)前處于集群環(huán)境中，支持分布式

在web.xml中添加選項 <distributable/>

第三種：session共享機(jī)制

使用分布式緩存方案比如memcached、redis，但是要求Memcached或Redis必須是集群。

使用Session共享也分兩種機(jī)制，兩種情況如下：

① 粘性session處理方式

原理：不同的 tomcat指定訪問不同的主memcached。多個Memcached之間信息是同步的，能主從備份和高可用。用戶訪問時首先在tomcat中創(chuàng)建session，然后將session復(fù)制一份放到它對應(yīng)的memcahed上。memcache只起備份作用，讀寫都在tomcat上。當(dāng)某一個tomcat掛掉后，集群將用戶的訪問定位到備tomcat上，然后根據(jù)cookie中存儲的SessionId找session，找不到時，再去相應(yīng)的memcached上去session，找到之后將其復(fù)制到備tomcat上。

② 非粘性session處理方式

原理：memcached做主從復(fù)制，寫入session都往從memcached服務(wù)上寫，讀取都從主memcached讀取，tomcat本身不存儲session

優(yōu)點(diǎn)：可容錯，session實時響應(yīng)。

實現(xiàn)方式：用開源的msm插件解決tomcat之間的session共享：Memcached_Session_Manager（MSM）

a. 復(fù)制相關(guān)jar包到tomcat/lib 目錄下

JAVA memcached客戶端：spymemcached.jarmsm項目相關(guān)的jar包：1. 核心包，memcached-session-manager-{version}.jar2. Tomcat版本對應(yīng)的jar包：memcached-session-manager-tc{tomcat-version}-{version}.jar序列化工具包：可選kryo，javolution,xstream等，不設(shè)置時使用jdk默認(rèn)序列化。

b. 配置Context.xml ，加入處理Session的Manager

粘性模式配置：

非粘性配置：

第四種：session持久化到數(shù)據(jù)庫

原理：就不用多說了吧，拿出一個數(shù)據(jù)庫，專門用來存儲session信息。保證session的持久化。

優(yōu)點(diǎn)：服務(wù)器出現(xiàn)問題，session不會丟失

缺點(diǎn)：如果網(wǎng)站的訪問量很大，把session存儲到數(shù)據(jù)庫中，會對數(shù)據(jù)庫造成很大壓力，還需要增加額外的開銷維護(hù)數(shù)據(jù)庫。

第五種terracotta實現(xiàn)session復(fù)制

原理：Terracotta的基本原理是對于集群間共享的數(shù)據(jù)，當(dāng)在一個節(jié)點(diǎn)發(fā)生變化的時候，Terracotta只把變化的部分發(fā)送給Terracotta服務(wù)器，然后由服務(wù)器把它轉(zhuǎn)發(fā)給真正需要這個數(shù)據(jù)的節(jié)點(diǎn)。可以看成是對第二種方案的優(yōu)化。

優(yōu)點(diǎn)：這樣對網(wǎng)絡(luò)的壓力就非常小，各個節(jié)點(diǎn)也不必浪費(fèi)CPU時間和內(nèi)存進(jìn)行大量的序列化操作。把這種集群間數(shù)據(jù)共享的機(jī)制應(yīng)用在session同步上，既避免了對數(shù)據(jù)庫的依賴，又能達(dá)到負(fù)載均衡和災(zāi)難恢復(fù)的效果。

實現(xiàn)方式：篇幅原因，下篇再論。

小結(jié)

以上講述的就是集群或分布式環(huán)境下，session的5種處理策略。其中就應(yīng)用廣泛性而言，第三種方式，也就是基于第三方緩存框架共享session，應(yīng)用的最為廣泛，無論是效率還是擴(kuò)展性都很好。而Terracotta作為一個JVM級的開源群集框架，不僅提供HTTP Session復(fù)制，它還能做分布式緩存，POJO群集，跨越群集的JVM來實現(xiàn)分布式應(yīng)用程序協(xié)調(diào)等，也值得學(xué)習(xí)一下。

總結(jié)

以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對大家的學(xué)習(xí)或者工作能帶來一定的幫助，如果有疑問大家可以留言交流，謝謝大家對VEVB武林網(wǎng)的支持。