分布式集群環境下的Session共享解決方案

2020-12-15 凱騰自媒體

HttpSession是通過Servlet容器創建和管理的,像Tomcat/Jetty都是保存在內存中的。而如果我們把web伺服器搭建成分布式的集群,然後利用LVS或Nginx做負載均衡,那麼來自同一用戶的Http請求將有可能被分發到兩個不同的web站點中去。那麼問題就來了,如何保證不同的web站點能夠共享同一份session數據呢?

最簡單的想法就是把session數據保存到內存以外的一個統一的地方,例如Memcached/Redis等資料庫中。那麼問題又來了,如何替換掉Servlet容器創建和管理HttpSession的實現呢?

(1)設計一個Filter,利用HttpServletRequestWrapper,實現自己的 getSession()方法,接管創建和管理Session數據的工作。spring-session就是通過這樣的思路實現的。

(2)利用Servlet容器提供的插件功能,自定義HttpSession的創建和管理策略,並通過配置的方式替換掉默認的策略。不過這種方式有個缺點,就是需要耦合Tomcat/Jetty等Servlet容器的代碼。這方面其實早就有開源項目了,例如memcached-session-manager,以及tomcat-redis-session-manager。暫時都只支持Tomcat6/Tomcat7。

Spring Session是Spring的項目之一,GitHub地址:https://github.com/spring-projects/spring-session。

Spring Session提供了一套創建和管理Servlet HttpSession的方案。Spring Session提供了集群Session(Clustered Sessions)功能,默認採用外置的Redis來存儲Session數據,以此來解決Session共享的問題。

Springboot集成步驟:

(1)Maven依賴

<dependency>

<groupId>org.springframework.session</groupId>

<artifactId>spring-session-data-redis</artifactId>

</dependency>

<dependency>

<groupId>org.springframework.boot</groupId>

<artifactId>spring-boot-starter-redis</artifactId>

</dependency>

(2)添加@EnableRedisHttpSession來開啟spring session支持,配置如下:

@Configuration

@EnableRedisHttpSession

public class RedisSessionConfig {

}

(3)Redis配置

spring.redis.host=localhostspring.redis.port=6379測試:

首先我們開啟兩個tomcat服務,埠分別為8080和9090

啟動之後進行訪問測試,首先訪問8080埠的tomcat

{"request Url":"http://localhost:8080/admin/v1/first"}

我們訪問8080埠的sessions,返回:

{"sessionId":"efcc85c0-9ad2-49a6-a38f-9004403776b5","message":"http://localhost:8080/admin/v1/first"}

再訪問9090埠的sessions,返回:

{"sessionId":"efcc85c0-9ad2-49a6-a38f-9004403776b5","message":"http://localhost:8080/admin/v1/first"}

8080與9090兩個伺服器返回結果一樣,實現了session的共享

相關焦點

  • Spring Cloud學習筆記—分布式下的Session共享該如何解決
    Spring Cloud學習筆記—分布式下的Session共享分布式下的Session在單應用的年代,基於Session來做用戶的登錄、退出等,總是令人感到輕鬆而愉快的。然而,在分布式下,情況變得複雜起來,如下:
  • 3分鐘讀懂何為分布式、微服務和集群!
    在分布式系統中,微服務更加強調單一職責、輕量級通信(HTTP)、獨立性並且進程隔離。好了,沒什麼好說的了,實踐出真知,建議大家多多了解 Spring-Cloud相關微服務組件。TT貓,每年都會搞一些活動,比如女生最愛的光棍節(雙11),夜深人靜的時候會瞬間湧入大量用戶,指不定就會把某個服務打趴下。這時候,問題來了用戶下單超時,或者直接500錯誤,如何去解決?
  • 淺談集群、分布式、微服務的異同
    高可用性集群的出現就是為了使集群的整體服務儘可能可用,以便考慮計算硬體和軟體的易錯性。如果高可用性集群中的主節點發生了故障,那麼這段時間內將由次節點代替它。次節點通常是主節點的鏡像,所以當它代替主節點時,它可以完全接管其身份。因此系統環境對於用戶是一致的。
  • 專家博客:探討分布式系統與集群的區別
    採用分布式方案,提供10臺伺服器,每臺伺服器只負責處理一個子任務,不考慮子任務間的依賴關係,執行完這個任務只需一個小時。  而採用集群方案,同樣提供10臺伺服器,每臺伺服器都能獨立處理這個任務。假設有10個任務同時到達,10個伺服器將同時工作,10小後,10個任務同時完成,這樣,整身來看,還是1小時內完成一個任務!
  • 集群_負載均衡_分布式的區別是什麼
    該系統具有的可用信道可為系統的全體用戶共用,具有自動選擇信道功能,它是共享資源、分擔費用、共用信道設備及服務的多用途、高效能的無線調度通信系統。是指一組獨立的計算機系統構成的一個鬆耦合的多處理器系統,它們之間通過網絡實現進程間的通信。應用程式可以通過網絡共享內存進行消息傳送,實現分布式計算機。通俗一點來說,就是讓若干臺計算機聯合起來工作(服務),可以是並行的,也可以是做備份。
  • 如何利用Node.js 構建分布式集群
    本文為UCloud 公司高級工程師文天樂在深JS大會上發表的演講內容,主要介紹了UCloud內部如何利用Node.js 構建分布式集群,並分享了實踐過程中走過的坑,希望對正在使用Node.js或是即將使用Node.js的朋友有一些幫助。
  • 分布式系列之一:架構的演進過程
    穩定性和可用性這兩個指標很難達到單機系統存在可用性和穩定性的問題,這兩個指標又是我們必須要去解決的 1、了解分布式架構中的相關概念 集群 小飯店原來只有一個廚師,切菜洗菜備料炒菜全乾。
  • 分布式鎖解決方案-Redis
    ## 為什麼要學習分布式鎖解決方案為了解決分布式架構帶來的數據準確性問題!我們用synchronized或者 ReentrantLock(瑞恩吹特) 能解決問題嗎?真實生產環境我們採用集群的方式去訪問秒殺商品(nginx為我們做了負載均衡)。
  • J2Cache 2.6.0 發布,支持分布式 session 存儲管理
    J2Cache 2.6.0 版本發布啦,該版本最最值得關注的就是支持分布式的 session 存儲管理,支持不同的 Servlet 容器。
  • session和cookie魅力所在
    cookie技術是客戶端解決方案(HTML5之後有了更好的替代品),其主要的特點是,伺服器發給客戶端的特殊信息以文本的形式存放在客戶端,之後客戶端每次向服務端發送請求時都會帶上這些信息。而session技術是服務端的解決方案,通過伺服器來保存狀態的。我們可以把伺服器和客戶端瀏覽器的一系列動作稱為一個Session,而Session是伺服器端為客戶端所開闢的存儲空間,其中保存的信息就是為了保存狀態。那麼如何使用session呢?
  • Apache Spark 1.6.1 發布,集群計算環境
    Apache Spark 1.6.1 發布了,Apache Spark 是一種與 Hadoop 相似的開源集群計算環境,但是兩者之間還存在一些不同之處
  • 集群和分布式,你知道其中的區別嗎?
    經常聽到MySql集群、Redis集群、分布式系統等概念,但是,很少有機會深究,到底什麼集群,什麼是分布式?在概念上這倆個詞很接近,難道不需要區分?其實,非常有必要區分這兩個概念,幫助我們對計算機的理論有更深入的理解。今天,我就嘗試去解釋一下這兩個概念。
  • 構建 Netflix 分布式追蹤(tracing)體系
    重建流 session 是一個繁瑣而耗時的過程,其中涉及到追蹤 Netflix 應用、CDN 網絡和後端微服務之間的所有交互(請求)。這個過程從手動拉取作 session 的用戶帳戶信息開始,並將所有的拼圖碎片放在一起,希望由此產生的全景能夠幫助解決用戶問題。因此需要通過分布式請求追蹤系統來提高生產力。
  • 一文看懂集群、分布式與負載均衡的關係
    在「高並發,海量數據,分布式,NoSql,雲計算......」概念滿天飛的年代,相信不少朋友都聽說過甚至常與人提起「集群,負載均衡」等,但不是所有人都有機會真正接觸到這些技術,也不是所有人都真正理解了這些「聽起來很牛的」技術名詞。下面簡單解釋一下吧。
  • 最常用的分布式 ID 解決方案,都在這裡了!
    「二、分布式ID實現方案」下表為一些常用方案對比:描述優點缺點UUIDUUID是通用唯一標識碼的縮寫,其目的是上分布式系統中的所有元素都有唯一的辨識信息,而不需要通過中央控制器來指定唯一標識。1. 降低全局節點的壓力,使得主鍵生成速度更快;2. 生成的主鍵全局唯一;3.
  • Infortrend CS分布式NAS集群優勢之高可用篇
    分布式作為大規模的集群存儲產品,要具備更加全面的防範措施,應對宕機、斷電等故障的發生。Infortrend EonStor CS分布式NAS集群存儲為確保前端業務持續不間斷使用,在硬體及軟體架構上嵌入多種技術理念來確保整個集群的高可用性。
  • 最常用的分布式ID解決方案,你知道幾個?
    二、分布式ID實現方案下表為一些常用方案對比:描述優點缺點UUIDUUID是通用唯一標識碼的縮寫,其目的是上分布式系統中的所有元素都有唯一的辨識信息,而不需要通過中央控制器來指定唯一標識。1. 降低全局節點的壓力,使得主鍵生成速度更快;2.
  • 5種分布式事務解決方案優缺點對比
    一致性:在分布式系統中的所有數據備份,在同一時刻是否同樣的值。 可用性:在集群中一部分節點故障後,集群整體是否還能響應客戶端的讀寫請求。 分區容忍性:以實際效果而言,分區相當於對通信的時限要求。系統如果不能在時限內達成數據一致性,就意味著發生了分區的情況,必須就當前操作在C和A之間做出選擇。
  • 如何優雅地用Redis實現分布式鎖?
    什麼是分布式鎖在學習Java多線程編程的時候,鎖是一個很重要也很基礎的概念,鎖可以看成是多線程情況下訪問共享資源的一種線程同步機制。這是對於單進程應用而言的,即所有線程都在同一個JVM進程裡的時候,使用Java語言提供的鎖機制可以起到對共享資源進行同步的作用。
  • 如何理解分布式與集群,二者區別是什麼?
    分布式是指不同的業務分布在不同的地方,集群指的是將幾臺伺服器集中在一起,實現同一業務。中期:用戶訪問量提高,伺服器崩了,為了解決這個問題,購買伺服器,增加伺服器數量,然後每個伺服器中個各放了一份,使用nginx代理轉發。(這就是運用集群原理)後期:用戶訪問量不斷增加,響應速度變慢,伺服器又崩了,在不考慮增加伺服器帶寬、內存和CPU的情況下如何解決這個問題?