分佈式環境下5種session處理策略

前言

在搭建完集羣環境後，不得不考慮的一個問題就是用戶訪問產生的session如何處理。若是不作任何處理的話，用戶將出現頻繁登陸的現象，好比集羣中存在A、B兩臺服務器，用戶在第一次訪問網站時，Nginx經過其負載均衡機制將用戶請求轉發到A服務器，這時A服務器就會給用戶建立一個Session。當用戶第二次發送請求時，Nginx將其負載均衡到B服務器，而這時候B服務器並不存在Session，因此就會將用戶踢到登陸頁面。這將大大下降用戶體驗度，致使用戶的流失，這種狀況是項目毫不應該出現的。

咱們應當對產生的Session進行處理，經過粘性Session，Session複製或Session共享等方式保證用戶的體驗度。

如下我將說明5種Session處理策略，並分析其優劣性。

第一種：粘性session

原理：粘性Session是指將用戶鎖定到某一個服務器上，好比上面說的例子，用戶第一次請求時，負載均衡器將用戶的請求轉發到了A服務器上，若是負載均衡器設置了粘性Session的話，那麼用戶之後的每次請求都會轉發到A服務器上，至關於把用戶和A服務器粘到了一塊，這就是粘性Session機制。 優勢：簡單，不須要對session作任何處理。 缺點：缺少容錯性，若是當前訪問的服務器發生故障，用戶被轉移到第二個服務器上時，他的session信息都將失效。 適用場景：發生故障對客戶產生的影響較小；服務器發生故障是低機率事件。 實現方式：以Nginx爲例，在upstream模塊配置ip_hash屬性便可實現粘性Session。

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

第二種：服務器session複製

原理：任何一個服務器上的session發生改變（增刪改），該節點會把這個 session的全部內容序列化，而後廣播給全部其它節點，無論其餘服務器需不須要session，以此來保證Session同步。 優勢：可容錯，各個服務器間session可以實時響應。 缺點：會對網絡負荷形成必定壓力，若是session量大的話可能會形成網絡堵塞，拖慢服務器性能。 實現方式： ① 設置tomcat ，server.xml 開啓tomcat集羣功能 Address:填寫本機ip便可，設置端口號，預防端口衝突。 ② 在應用裏增長信息：通知應用當前處於集羣環境中，支持分佈式 在web.xml中添加選項 <distributable/>

第三種：session共享機制

使用分佈式緩存方案好比memcached、Redis，可是要求Memcached或Redis必須是集羣。 使用Session共享也分兩種機制，兩種狀況以下：

粘性session處理方式

原理：不一樣的 tomcat指定訪問不一樣的主memcached。多個Memcached之間信息是同步的，能主從備份和高可用。用戶訪問時首先在tomcat中建立session，而後將session複製一份放到它對應的memcahed上。memcache只起備份做用，讀寫都在tomcat上。當某一個tomcat掛掉後，集羣將用戶的訪問定位到備tomcat上，而後根據cookie中存儲的SessionId找session，找不到時，再去相應的memcached上去session，找到以後將其複製到備tomcat上。 ② 非粘性session處理方式

原理：memcached作主從複製，寫入session都往從memcached服務上寫，讀取都從主memcached讀取，tomcat自己不存儲session

優勢：可容錯，session實時響應。 實現方式：用開源的msm插件解決tomcat之間的session共享：

Memcached_Session_Manager（MSM）
a. 複製相關jar包到tomcat/lib 目錄下
JAVA memcached客戶端：spymemcached.jar

msm項目相關的jar包：

1. 核心包，memcached-session-manager-{version}.jar
2. Tomcat版本對應的jar包：memcached-session-manager-tc{tomcat-version}-{version}.jar

序列化工具包：可選kryo，javolution,xstream等，不設置時使用jdk默認序列化。
b. 配置Context.xml ，加入處理Session的Manager

粘性模式配置：

這裏寫圖片描述 非粘性配置： 這裏寫圖片描述

第四種：session持久化到數據庫

原理：就不用多說了吧，拿出一個數據庫，專門用來存儲session信息。保證session的持久化。 優勢：服務器出現問題，session不會丟失 缺點：若是網站的訪問量很大，把session存儲到數據庫中，會對數據庫形成很大壓力，還須要增長額外的開銷維護數據庫。

第五種terracotta實現session複製 原理：Terracotta的基本原理是對於集羣間共享的數據，當在一個節點發生變化的時候，Terracotta只把變化的部分發送給Terracotta服務器，而後由服務器把它轉發給真正須要這個數據的節點。能夠當作是對第二種方案的優化。 優勢：這樣對網絡的壓力就很是小，各個節點也沒必要浪費CPU時間和內存進行大量的序列化操做。把這種集羣間數據共享的機制應用在session同步上，既避免了對數據庫的依賴，又能達到負載均衡和災難恢復的效果。

實現方式：篇幅緣由，下篇再論。

小結

以上講述的就是集羣或分佈式環境下，session的5種處理策略。其中就應用普遍性而言，第三種方式，也就是基於第三方緩存框架共享session，應用的最爲普遍，不管是效率仍是擴展性都很好。而Terracotta做爲一個JVM級的開源羣集框架，不只提供HTTP Session複製，它還能作分佈式緩存，POJO羣集，跨越羣集的JVM來實現分佈式應用程序協調等，也值得學習一下。