WEB應用開發完成后部署到Tomcat或其他容器中供用戶訪問. 小型應用在一臺服務器上安裝Tomcat并部署WEB應用. 隨著訪問量增大, Tomcat的壓力會越來越大, 直至崩潰. 為了保證WEB應用的承載能力, 需要對WEB應用進行集群處理.

技術發展到今天, 集群/負載均衡已經變的相對簡單了. 下面用通俗的語言給剛入門的同學介紹下這兩個概念:

某KFC開業時只有一個點餐窗口(一臺Tocmat服務器, 可以節約成本)對外提供點餐服務. 應對日常點餐沒有問題, 當飯口或者周末時一個窗口就會排起長隊(高并發). 不僅顧客有怨言(請求響應時間長, 用戶體驗差), 服務員也會很累, 終于有一天他累倒了(Tomcat掛掉了).

這時在側面增加了一個窗口(增加一臺Tomcat服務器)提供點餐服務, 但是很多顧客不知道新窗口, 依舊在原有窗口排起了長隊(用戶依舊訪問原來的Tomcat), 這時需要有一個人專門站在門口根據每個窗口的排隊情況指引顧客去哪個窗口點餐(負載均衡器). 這個人作用是為了讓各個窗口的點餐人數大致相等, 避免有的窗口很忙, 有的很閑. 隨著顧客增加, 點餐窗口也會相應增加(Tomcat越來越多).

• 集群: 一群服務器集合在一起提供服務, 上例中多個點餐窗口(多臺Tomcat)共同提供點餐服務就是集群.
• 負載均衡: 讓集群中每個點餐窗口(每個Tomcat)的負載情況保持均衡, 不要出現某一個或幾個太空閑.
  

兩個概念是同時出現的, 沒有集群的服務(單一Tomcat)也不存在負載均衡之說, 集群的服務沒有負載均衡會浪費資源.

WEB負載均衡方案很多, Nginx + Tomcat 是常用的方案之一. Nginx作為負載均衡器根據每個Tomcat的負載情況進行分流.

• 每個Tomcat都相當于點餐窗口, 都可以提供點餐服務
• 每次要點餐都得先經過Nginx
• Nginx會根據每個窗口的空閑情況進行分配用戶去哪個窗口點餐
• 第一次在1號窗口點餐, 點完后馬上再次點餐, 有可能被分配到2號窗口
  

下面我們搭建負載均衡的WEB應用

1) 搭建WEB應用

準備WEB應用, 用兩個Tomcat部署, 測試時為了能夠區分請求是由哪個Tomcat進行處理, 將Tomcat端口號作為結果返回.

/** * 獲取部署項目的Tomcat端口號 */@RequestMapping("/port/get")@ResponseBodypublic String getPort(HttpServletRequest request) { return String.valueOf(request.getLocalPort());}

本例中分別使用 5677 , 5688 兩個端口部署該項目. 訪問 /port/get 請求返回結果為Tomcat的端口號

http:// localhost:5677/port/get
http:// localhost:5688/port/get

2) Nginx配置負載均衡

Window下Nginx安裝比較簡單, 不會安裝的同學自行百度, 簡單介紹下Nginx配置文件: nginx.conf

# Nginx進程數worker_processes 1;events { # 最大并發鏈接數 worker_connections 1024;}# Nginx處理HTTP請求相關的配置# http不能重復, 全局唯一http { # 虛擬主機, 可配置多個虛擬主機 # Nginx監聽88,89,90三個端口, 可配置三個server server { # 端口號, 訪問88端口會都按照該server下的配置進行處理 listen 88; # 主機名稱 server_name localhost; # 根據正則表達式匹配URL, 匹配到的URL按照該location下的配置進行處理 # /代表訪問88端口的所有請求 location / { # 靜態資源所在根目錄, 會從該目錄下查找靜態資源 # 例: 訪問/a.html, 找到D:/a.html并返回 root D:/; } } }

上述配置文件最基礎的Nginx配置, 當我們訪問 http://localhost:88 時會由Nginx處理, 下面我們配置Nginx的負載均衡.

配置1)中定義的兩個tomcat, 在 http 節點下添加如下代碼:

# 定義需要進行負載均衡的服務器信息# upstream為關鍵字, springsession為自定義的名稱# server為關鍵字, 代表一個服務或服務(一個tomcat)# server的內容為服務器的信息, 形式為ip:端口# weight定義了服務器負載的權重, 每4次請求有3次轉發到5688, 1次到5677upstream springsession {  server localhost:5677 weight=1;  server localhost:5688 weight=3; }

配置當訪問Nginx的所有請求轉發至兩個服務器處理

location / { # root D:/; # 轉發至名稱為springsession的upstream處理 proxy_pass http://springsession; }

3) 測試負載均衡

訪問 http://localhost:88/port/get , Nginx將請求轉發至兩臺tomcat中的一個進行處理. 可以發現請求返回的結果是不一樣的

• 根據配置的權重, 每4次訪問有3次由 5688 上, 1次由 5677 處理.
• 權重配置只是最終平均值為3/4和1/4, 不一定是前三次訪問都會由 5688 處理.
• 不配置weight時, 一次請求兩個tomcat被分配到的概率各占50%
  

負載均衡配置好了, 有這樣一個問題:

你在1號窗口點餐時把鑰匙暫存到該窗口, 下次在點餐可能被分配到2號窗口或其他窗口(也有可能分配到1號窗口), 那么在其他窗口取鑰匙顯然是行不通的. 因為其他窗口沒有你的鑰匙. 這時你只能祈禱能快速把你分配到1號窗口.

如果保存鑰匙的操作變為在SESSION中保存信息, 那么當你的請求被 Tomcat1 處理時, Tomcat1 會為你生成一個SESSION, 你在SESSION里面設置了信息, 下次你的請求被分配到 Tomcat2 處理, Tomcat2 又會為你生成一個SESSION. 這是兩個獨立的并且不共享的SESSION. 因此你是不可能的在 Tomcat2 中獲取你在 Tomcat1 中保存的信息.

登錄的原理其實就是在SESSION中保存登錄狀態, 按照上面的分析, 登錄在集群部署的服務中就失效了. 在Tomcat1中登錄, 下次訪問Tomcat2, 此時通過SESSION判斷登錄狀態得到的一定是未登錄, 還需要再次登錄. 用戶瘋, 你瘋, 老板也會瘋...

如果有一個公用位置用來存放東西, 所有的點餐窗口都在公用位置存取顧客物品, 上面的問題就迎刃而解了.

這就是本文重點: 統一管理集群下各WEB應用的SESSION .

• 容器的選擇: 我們需要一個能夠統一存放SESSION的容器. 從以下3點分析, Redis 無疑是最合適的. SESSION是經常被讀取的, 因此數據庫, 文件系統均不適合, 最好是從內存操作. SESSION是有ID的, 一個ID對應一個SESSION, 最好是一個K/V的容器 SESSION是有時效性的(時間長不用, 需要刪除). 最好能夠設置過期時間
• SESSION存取機制: 由于SESSION是Tomcat生成的, 因此首先想到的是修改Tomcat的SESSION機制, 從 Redis 中存取SESSION, 這樣會帶來一個問題, 假設Tocmat升級了, 我們還需要重新對Tomcat進行修改. 因此這個方案可行性較差. 我們可以這樣考慮, 即使Tomcat生成了SESSION, 我們也是在WEB應用中使用, 為什么不在WEB應用中重新生成一個SESSION呢, 編寫這樣一個過濾器, 在進入WEB應用之前, 拋棄Tomcat的SESSION, 從 Redis 中獲取SESSION.

恰巧有這樣一個框架幫助我們完成上面的想法, 只需要配置一下即可實現統一管理SESSION. 他就是 Spring Session .

為了對 Spring Session 的功能印象深刻, 我們先來測試一下沒有Spring Session時我們的集群應用是怎樣處理SESSION的

把我們負載均衡的WEB應用中增加一個控制器方法, 把每次的 SESSION ID 輸出一下.

/** * 獲取部署項目的SESSION ID */@RequestMapping("/sessionid/get")@ResponseBodypublic String getPort(HttpServletRequest request, HttpSession session) { int port = request.getLocalPort(); // 端口 String sessionId = request.getSession().getId(); // SESSION ID  return "port: " + port + ", session id: " + sessionId;}

啟動項目, 多次訪問 http://localhost:88/sessionid/get

兩次訪問都在同一Tomcat下的SESSOIN ID是不變的
兩次訪問在不同的Tomcat下的SESSION ID是變化的
訪問不同的Tomcat后, 再次訪問同一Tomcat時SESSION ID也是變化的

出現上述情況的原因如下:

1. 訪問 5677 , 由于沒有SESSION, Tomcat5677 生成SESSION, ID為 1 , 并將 1 返回客戶端
2. 訪問 5677 , 瀏覽器攜帶 SESSION_ID=1 , Tomcat5677 找到對應的SESSION. 因此SESSION_ID為 1
3. 訪問 5688 , 瀏覽器攜帶 SESSION_ID=1 , Tomcat5688 找不到對應的SESSION, 重新生成SESSION, ID為 2 , 并將 2 返回客戶端
4. 訪問 5677 , 瀏覽器攜帶 SESSION_ID=2 , Tomcat5677 找不到對應的SESSION, 重新生成SESSION, ID為 3 , 并將 3 返回客戶端
5. 訪問 5688 , 瀏覽器攜帶 SESSION_ID=3 , Tomcat5688 找不到對應的SESSION, 重新生成SESSION, ID為 4 , 并將 4 返回客戶端

4) 統一SESSION管理

下面我們來用 Spring Session 來管理WEB應用的SESSION

1) 安裝Redis并開啟

參見文章http://www.49028c.com/article/145704.htm

2) 添加Spring Session依賴

// Spring Session依賴"org.springframework.session:spring-session-data-redis:2.0.5.RELEASE",// Redis依賴"io.lettuce:lettuce-core:5.0.4.RELEASE"

3) 配置Spring Session過濾器

在 Web.xml 中配置 Spring Session 提供的過濾器, 該過濾器主要負責將Tomcat生成的SESSION替換成Redis中保存的SESSION.

<!-- Spring Session過濾器 --><!-- 負責在進入WEB應用之前將Tomcat生成的SESSION替換為Redis中的SESSION --><filter> <filter-name>springSessionRepositoryFilter</filter-name> <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class></filter><filter-mapping> <filter-name>springSessionRepositoryFilter</filter-name> <url-pattern>/*</url-pattern></filter-mapping>

4) SpringSession/Redis配置

在Spring配置文件中增加 Spring Session 配置和 Redis 配置

beans { xmlns context: "http://www.springframework.org/schema/context" // 啟動注解方式 context.'annotation-config'() // 配置Spring Session // 實際上是配置Web.xml中使用的Spring Session過濾器 // 將Tomcat的Session替換為Redis中管理的Session sessionConfig(RedisHttpSessionConfiguration) // 配置Redis客戶端連接 // 默認連接本地6379端口 lettuce(LettuceConnectionFactory) }

5) 測試

啟動項目, 多次訪問 http://localhost:88/sessionid/get , 無論如何訪問 SESSION ID 都是一樣的.

同時 Redis 中也出現了當前SESSION的記錄.

使用 Spring Session 后訪問集群下的WEB應用時SESSION處理過程:

1. 訪問 5677 , 由于 Redis 中沒有 SESSION , 因此會生成一個 SESSION 并存入 Redis , ID為 1 , 并將 1 返回客戶端
2. 訪問 5677 , 瀏覽器攜帶 SESSION_ID=1 , Tomcat5677 在 Redis 中找到了 SESSION . 因此 SESSION_ID 為 1
3. 訪問 5688 , 瀏覽器攜帶 SESSION_ID=1 , Tomcat5688 在 Redis 中找到了 SESSION . 因此 SESSION_ID 為 1
4. 清除 Redis , 再次訪問 5677 , 由于 Redis 中沒有ID為 1 的 SESSION , 因此會重新生成, ID也相應變化了

5) 示例代碼

此時我們已經實現了統一管理SESSION, 無論訪問任一TOMCAT都可以找到相同的SESSION.

當我們的應用進行集群后, 統一管理SESSION勢在必行, 實現統一管理SESSION的方式很多, 本文只是其中一種方式. 重在讓同學們理解統一管理SESSION的重要性和他的基本原理.

示例代碼地址: https://github.com/atd681/alldemo

示例項目名稱: atd681-springsession

總結

以上所述是小編給大家介紹的SpringSession+Redis實現集群會話共享的方法，希望對大家有所幫助，如果大家有任何疑問請給我留言，小編會及時回復大家的。在此也非常感謝大家對武林網網站的支持！