SpringSession+Redis實現(xiàn)集群會話共享的方法

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

技術(shù)發(fā)展到今天, 集群/負載均衡已經(jīng)變的相對簡單了. 下面用通俗的語言給剛?cè)腴T的同學(xué)介紹下這兩個概念:

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

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

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

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

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

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

下面我們搭建負載均衡的WEB應(yīng)用

1) 搭建WEB應(yīng)用

準(zhǔn)備WEB應(yīng)用, 用兩個Tomcat部署, 測試時為了能夠區(qū)分請求是由哪個Tomcat進行處理, 將Tomcat端口號作為結(jié)果返回.

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

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

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

2) Nginx配置負載均衡

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

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

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

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

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

配置當(dāng)訪問Nginx的所有請求轉(zhuǎn)發(fā)至兩個服務(wù)器處理

location / {
 # root D:/;
 # 轉(zhuǎn)發(fā)至名稱為springsession的upstream處理
 proxy_pass http://springsession; 
}

3) 測試負載均衡

訪問 http://localhost:88/port/get , Nginx將請求轉(zhuǎn)發(fā)至兩臺tomcat中的一個進行處理. 可以發(fā)現(xiàn)請求返回的結(jié)果是不一樣的

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

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

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

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

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

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

這就是本文重點: 統(tǒng)一管理集群下各WEB應(yīng)用的SESSION .

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

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

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

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

/**
 * 獲取部署項目的SESSION ID
 */
@RequestMapping("/sessionid/get")
@ResponseBody
public 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也是變化的

出現(xiàn)上述情況的原因如下:

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

4) 統(tǒng)一SESSION管理

下面我們來用 Spring Session 來管理WEB應(yīng)用的SESSION

1) 安裝Redis并開啟

參見文章https://www.jb51.net/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 提供的過濾器, 該過濾器主要負責(zé)將Tomcat生成的SESSION替換成Redis中保存的SESSION.

!-- Spring Session過濾器 -->
!-- 負責(zé)在進入WEB應(yīng)用之前將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客戶端連接
 // 默認(rèn)連接本地6379端口
 lettuce(LettuceConnectionFactory)
 
}

5) 測試

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

同時 Redis 中也出現(xiàn)了當(dāng)前SESSION的記錄.

使用 Spring Session 后訪問集群下的WEB應(yīng)用時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也相應(yīng)變化了

5) 示例代碼

此時我們已經(jīng)實現(xiàn)了統(tǒng)一管理SESSION, 無論訪問任一TOMCAT都可以找到相同的SESSION.

當(dāng)我們的應(yīng)用進行集群后, 統(tǒng)一管理SESSION勢在必行, 實現(xiàn)統(tǒng)一管理SESSION的方式很多, 本文只是其中一種方式. 重在讓同學(xué)們理解統(tǒng)一管理SESSION的重要性和他的基本原理.

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

示例項目名稱: atd681-springsession

總結(jié)

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