問題描述
先來了解一下Session是什麼
Session在計算機中,被稱爲＂會話控制＂．Session對象儲存特定用戶回話所需的屬性及配置信息.這樣,當用戶在應用程序的web頁之間跳轉時,存儲在Session對象中的變量將不會丟失,而是在整個用戶的會話中一種存在下去.
問題深入
在Tomcat中,Session實際上就是我們在內存中的一段空間.當我們的用戶要在服務器上存儲一個信息的時候,tomcat會在自己本機的內存空間裏開闢一個位置來存儲這個信息.多個用戶構成一個集合,所以的都是在tomcat自己的內存空間裏的,所以說只是存在本機的空間裏的.
那麼在負載均衡的情況下,如上圖,如果用戶之前訪問被分配到tomcat1,這個時候存儲在Session中一個值,而後第二次訪問被分配到tomcat2這種情況下,按照我們之前的考慮思路,肯定是獲取不到相應的Session信息.這就是我們在分佈式的負載均衡的情況下Session存在的問題.
通常情況下有3種策略
類似於ip_hash的用戶鎖定的方式(不容錯的方案)
將用戶鎖定到某一臺機器上,比如說把同一個用戶的請求鎖定到tomcat1上,那麼這個用戶只能訪問tomcat1,那麼他的第二次,第三次,第n次訪問的都是同一個tomcat,就不會出現之前所說的問題.這種處理方式簡單,但是缺乏容錯性,如果因爲某種原因該臺機器掛掉,那麼後續的請求轉發到其他服務器上,那麼用戶的session狀態就會丟失,就會感知到錯誤的發生.比如說他突然發現自己本來的登錄狀態成了未登錄狀態.缺點雖說是這個樣子,是可以接受的.因爲它的發生機率還是極低的,考慮到具體的應用場景來說,在某些方面是可以應用的.說它的發生概率低是因爲一個正常運行的集羣系統,如果說經常會發生服務器掛掉,要麼就是你的硬件出了問題,要麼就是你的應用出了問題;再者就是要考慮當放生錯誤的額時候,對用戶的業務產生多大的影響.
Session複製(有容錯功能的方案)
在集羣環境中,當其任何一臺服務器上的Session狀態或者信息發生改變的時候,在這種情況出現的時候,它會向整個網絡裏發送廣播,通知它的Session改變事件,其他的服務器有接受廣播的功能,在接收到消息之後,會將Session進行對應的改變,達到同步的目的.它的優點顯而易見,除了容錯性之外,還有就是Session同步的功能.但是缺點也挺明顯,首先它發送的是網絡廣播,一臺服務器Session的改變就要發送廣播,其他的都要發生改變,會對網絡造成特別大的壓力.尤其是當你集羣中的服務器特別多,tomcat特別多,在就是Session的數據量特別大的時候,像這種大批量的網絡複製會極大地消耗後端性能,甚至造成網絡的阻塞或者癱瘓.所以說該種方案最大的缺陷就是性能的低下甚至會造成一些列的故障.
Sessionfuzhi的實現:
在tomcat中的server.xml文檔中(最後一個connector裏的engine模塊裏,有註釋提示)
<!-- 基於網絡廣播的策略,一個節點session變換,其他節點同步複製,節點多或者數據量大時功能性能低下-->
<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster">
<!--網絡通道對象-->
<Channel className="org.apache.catalina.tribes.group.GroupChannel">
<!--接收器對象-->
<Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver" address="auto"
port="4000"/>
</Channel>
</Cluster>在tomcat7以後,server.xml取消Cluster這行註釋之後表示tomcat開啓了集羣功能.tomcat的集羣功能配備了發送器,接收器,內容轉換器,還有各種監聽藉口,事件顯示器等一系列功能.以上是在tomcat中的要進行修改的,對應的在開發的應用中要在web.xml中添加這麼一條配置選項,位置如下圖.添加完這兩項配置後,這個應用就有了session複製的功能了.
補充:
需要說明的是,因爲在一臺服務器上可能不止有一個tomcat,在配置參數的時候,不要使用默認參數,要自行進行手動配置.首先要考慮的就是端口衝突問題.比如上方的示例,如果一臺服務器上有兩個tomcat,默認指定不同端口.地址也是一樣,因爲開啓該項功能,如果設置的是auto,會自動選擇,如果選擇錯了,那麼也就不能進行.通常服務器有兩個網卡,一個是內網網卡,一個是外網的,我們的接收器是綁定在內網上的.因爲我們的服務器集羣是在內網的,所以接收器自然綁定的是內網的網卡,如果綁錯了就會接收不到消息.