2. 程式人生 > 資料庫 >SpringSession+Redis實現叢集會話共享的方法

SpringSession+Redis實現叢集會話共享的方法

阿新 • • 發佈：2020-01-09

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")
@ResponseBody
public 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次到5677
upstream 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")
@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也是變化的

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

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

4) 統一SESSION管理

下面我們來用 Spring Session 來管理WEB應用的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 提供的過濾器,該過濾器主要負責將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,Tomcat5677 在 Redis 中找到了 SESSION . 因此 SESSION_ID 為 1
  2. 訪問 5688,Tomcat5688 在 Redis 中找到了 SESSION . 因此 SESSION_ID 為 1
  3. 清除 Redis,再次訪問 5677,由於 Redis 中沒有ID為 1 的 SESSION,因此會重新生成,ID也相應變化了

5) 示例程式碼

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

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

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

示例專案名稱: atd681-springsession

總結

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

相關推薦

SpringSession+Redis實現叢集會話共享的方法

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

SpringBoot+SpringSession+Redis實現session共享及唯一登入

轉載：https://blog.csdn.net/xjj1040249553/article/details/82658889 一、pom.xml配置 <dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-data-

SpringSession 依賴redis實現使用者會話

前提 springboot框架版本 <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId>

基於redis實現定時任務的方法詳解

前言 業務中碰到的需求（抽象描述一下）：針對不同的使用者能夠實現不同時間的間隔迴圈任務。比如在使用者註冊成功24小時後給使用者推送相關簡訊等類似需求。

redis實現排行榜的簡單方法

1 前言 實現一個排版榜，我們通常想到的就是mysql的order by 簡單粗暴就擼出來了。但是這樣真的優雅嗎？

MySQL和Redis實現二級快取的方法詳解

redis簡介 Redis 是完全開源免費的，遵守BSD協議，是一個高效能的key-value資料庫

通過Nginx+Tomcat+Redis實現持久會話

使用開源web應用solo blog進行專案演示。前端使用Nginx作為負載均衡器，後端Tomcat連線Redis實現session儲存。Redis的特點就是可以將session持久化。樣才能真正實現後臺多個Tomcat負載平衡，使用者請求能夠發往任何

Redis實現分散式鎖的方法示例

之前我們使用的定時任務都是隻部署在了單臺機器上，為了解決單點的問題，為了保證一個任務，只被一臺機器執行，就需要考慮鎖的問題，於是就花時間研究了這個問題。到底怎樣實現一個分散式鎖呢？

redis實現mysql鎖的方法

redis實現mysql鎖的方法 $config = array( \'host\'=> \'localhost\', \'port\'=> 6379, \'index\'=> 0,

SpringBoot+Redis實現資料字典的方法

前言 我們在日常的開發過程中針對一些欄位採用整型的方式去代替某些具體的含義，比如性別0代表男，1代表女。如果只是一些不會變更的轉譯我們可以採用常量或者列舉類的方式來實現，但是事實上我們也會遇到那種可能需要

Redis實現分散式鎖的方法總結

這兩天在看分散式鎖相關的知識，看到一篇文章，分享給大家，附上原文連結https://www.jb51.net/article/118312.htm

SpringCloud Gateway使用redis實現動態路由的方法

1. 將 actuator 端點暴露出來 management: endpoints: web: exposure: include: \"*\" 2. redis 配置 https://www.jb51.net/article/203766.htm

使用Redis實現分散式會話

1. 概述 傳統的單體應用中，使用者是否登入，通常是通過從Tomcat容器的session中獲取登入使用者資訊判斷的。

Shiro結合Redis實現分散式或叢集環境下的Session共享

本篇是Shiro系列第二篇，使用Shiro基於Redis實現分散式或叢集環境下的Session共享。在講Session共享之前先說一下為什麼要做Session共享。

Shiro+Redis實現Tomcat叢集Session共享

一、背景 　　當我們使用了nginx做專案叢集以後，就會出現一個很嚴重的問題亟待解決，那就是：tomcat叢集之間如何實現session共享的問題，如果這個問題不解決，就會出現登陸過後再次請求資源依舊需要登陸的問題。這

Redis實現布隆過濾器的方法及原理

布隆過濾器（Bloom Filter）是1970年由布隆提出的。它實際上是一個很長的二進位制向量和一系列隨機對映函式。布隆過濾器可以用於檢索一個元素是否在一個集合中。它的優點是空間效率和查詢時間都比一般的演算法要好的

非同步redis佇列實現 資料入庫的方法

業務需求 app客戶端向服務端介面傳送來json 資料 每天 發一次 清空快取後會再次傳送

redis實現分散式的方法總結

一 為什麼使用 Redis 在專案中使用 Redis，主要考慮兩個角度：效能和併發。如果只是為了分散式鎖這些其他功能，還有其他中介軟體 Zookpeer 等代替，並非一定要使用 Redis。

Redis實現分散式鎖和等待序列的方法示例

在叢集下，經常會因為同時處理髮生資源爭搶和併發問題，但是我們都知道同步鎖synchronized 、cas 、ReentrankLock 這些鎖的作用範圍都是JVM ，說白了在叢集下沒啥用。這時我們就需要能在多臺JVM 之間決定執行順序的

基於docker搭建redis-sentinel叢集的方法示例

1、概述 Redis 叢集可以在一組 redis 節點之間實現高可用性和 sharding。在叢集中會有 1 個 master 和多個 slave 節點。當 master 節點失效時，應選舉出一個 slave 節點作為新的 master。然而 Redis 本身(包括它的很