0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認識你,還能領取20積分哦,立即完善>

3天內不再提示

分布式Session一致性及其作用

馬哥Linux運維 ? 來源:SimpleWu ? 2023-03-14 15:07 ? 次閱讀

分布式Session一致性?

說白了就是服務器集群Session共享的問題

Session的作用?

Session 是客戶端與服務器通訊會話跟蹤技術,服務器與客戶端保持整個通訊的會話基本信息。

客戶端在第一次訪問服務端的時候,服務端會響應一個sessionId并且將它存入到本地cookie中,在之后的訪問會將cookie中的sessionId放入到請求頭中去訪問服務器,如果通過這個sessionid沒有找到對應的數(shù)據(jù)那么服務器會創(chuàng)建一個新的sessionid并且響應給客戶端。

分布式Session存在的問題?

假設第一次訪問服務A生成一個sessionid并且存入cookie中,第二次卻訪問服務B客戶端會在cookie中讀取sessionid加入到請求頭中,如果在服務B通過sessionid沒有找到對應的數(shù)據(jù)那么它創(chuàng)建一個新的并且將sessionid返回給客戶端,這樣并不能共享我們的Session無法達到我們想要的目的。

解決方案:

使用cookie來完成(很明顯這種不安全的操作并不可靠)

使用Nginx中的ip綁定策略,同一個ip只能在指定的同一個機器訪問(不支持負載均衡)

利用數(shù)據(jù)庫同步session(效率不高)

使用tomcat內置的session同步(同步可能會產生延遲)

使用token代替session

我們使用spring-session以及集成好的解決方案,存放在redis中

目前項目中存在的問題

啟動兩個項目端口號分別為8080,8081。

依賴:

 

org.springframework.boot
spring-boot-starter-parent
2.1.1.RELEASE
 


 

org.springframework.boot
spring-boot-starter-web


創(chuàng)建測試類:

/**
*Author:SimpleWu
*date:2018/12/14
*/
@RestController
publicclassTestSessionController{

@Value("${server.port}")
privateIntegerprojectPort;//項目端口

@RequestMapping("/createSession")
publicStringcreateSession(HttpSessionsession,Stringname){
session.setAttribute("name",name);
return"當前項目端口:"+projectPort+"當前sessionId:"+session.getId()+"在Session中存入成功!";
}

@RequestMapping("/getSession")
publicStringgetSession(HttpSessionsession){
return"當前項目端口:"+projectPort+"當前sessionId:"+session.getId()+"獲取的姓名:"+session.getAttribute("name");
}

}

yml配置:

server:
port:8080

修改映射文件

#將本機ip映射到www.hello.com上
127.0.0.1www.hello.com

在這里我們開啟nginx集群,修改配置:

#加入
#默認使用輪詢,
upstreambackserver{
server127.0.0.1:8080;
server127.0.0.1:8081;
}
#修改server中的local
location/{
proxy_passhttp://backserver;
indexindex.htmlindex.htm;
}

我們直接通過輪詢機制來訪問首先向Session中存入一個姓名,http://www.hello.com/createSession?name=SimpleWu

“當前項目端口:8081 當前sessionId :0F20F73170AE6780B1EC06D9B06210DB在Session中存入成功!

因為我們使用的是默認的輪詢機制那么下次肯定訪問的是8080端口,我們直接獲取以下剛才存入的值http://www.hello.com/getSession

“當前項目端口:8080 當前sessionId :C6663EA93572FB8DAE27736A553EAB89 獲取的姓名:null

這個時候發(fā)現(xiàn)8080端口中并沒有我們存入的值,并且sessionId也是與8081端口中的不同。

別急繼續(xù)訪問,因為輪詢機制這個時候我們是8081端口的服務器,那么之前我們是在8081中存入了一個姓名。那么我們現(xiàn)在來訪問以下看看是否能夠獲取到我們存入的姓名:SimpleWu,繼續(xù)訪問:http://www.hello.com/getSession

“當前項目端口:8081 當前sessionId :005EE6198C30D7CD32FBD8B073531347 獲取的姓名:null

為什么8080端口我們沒有存入連8081端口存入的都沒有了呢?

我們仔細觀察一下第三次訪問8081的端口sessionid都不一樣了,是因為我們在第二次去訪問的時候訪問的是8080端口這個時候客戶端在cookie中獲取8081的端口去8080服務器上去找,沒有找到后重新創(chuàng)建了一個session并且將sessionid響應給客戶端,客戶端又保持到cookid中替換了之前8081的sessionid,那么第三次訪問的時候拿著第二次訪問的sessionid去找又找不到然后又創(chuàng)建。一直反復循環(huán)。

如何解決這兩個服務之間的共享問題呢?

spring已經(jīng)給我們想好了問題并且已經(jīng)提供出解決方案:spring-session 不了解的可以去百度了解下。

我們首先打開redis并且在pom.xml中添加依賴:


com.alibaba
fastjson
1.2.47


org.springframework.boot
spring-boot-starter-data-redis

 

org.springframework.session
spring-session-data-redis


org.apache.commons
commons-pool2


redis.clients
jedis

修改yml配置文件:

server:
port:8081
spring:
redis:
database:0
host:localhost
port:6379
jedis:
pool:
max-active:8
max-wait:-1
max-idle:8
min-idle:0
timeout:10000
redis:
hostname:localhost
port:6379
#password:123456

添加Session配置類

/**
*Author:SimpleWu
*date:2018/12/14
*/
//這個類用配置redis服務器的連接
//maxInactiveIntervalInSeconds為SpringSession的過期時間(單位:秒)
@EnableRedisHttpSession(maxInactiveIntervalInSeconds=1800)
publicclassSessionConfig{

//冒號后的值為沒有配置文件時,制動裝載的默認值
@Value("${redis.hostname:localhost}")
privateStringhostName;
@Value("${redis.port:6379}")
privateintport;
//@Value("${redis.password}")
//privateStringpassword;

@Bean
publicJedisConnectionFactoryconnectionFactory(){
JedisConnectionFactoryconnection=newJedisConnectionFactory();
connection.setPort(port);
connection.setHostName(hostName);
//connection.setPassword(password);
//connection.setDatabase(0);
returnconnection;
}
}

初始化Session配置

/**
*Author:SimpleWu
*date:2018/12/14
*/
//初始化Session配置
publicclassSessionInitializerextendsAbstractHttpSessionApplicationInitializer{
publicSessionInitializer(){
super(SessionConfig.class);
}
}

然后我們繼續(xù)啟動8080,8081來進行測試:

首先存入一個姓名

“當前項目端口:8080 當前sessionId :cf5c029a-2f90-4b7e-8345-bf61e0279254在Session中存入成功!

應該輪詢機制那么下次一定是8081,竟然已經(jīng)解決session共享問題了那么肯定能夠獲取到了,竟然這樣那么我們直接來獲取下姓名

“當前項目端口:8081 當前sessionId :cf5c029a-2f90-4b7e-8345-bf61e0279254 獲取的姓名:SimpleWu

這個時候我們發(fā)現(xiàn)不僅能夠獲取到值而且連sessionid都一致了。

實現(xiàn)原理:

就是當Web服務器接收到http請求后,當請求進入對應的Filter進行過濾,將原本需要由web服務器創(chuàng)建會話的過程轉交給Spring-Session進行創(chuàng)建,本來創(chuàng)建的會話保存在Web服務器內存中,通過Spring-Session創(chuàng)建的會話信息可以保存第三方的服務中,如:redis,mysql等。Web服務器之間通過連接第三方服務來共享數(shù)據(jù),實現(xiàn)Session共享!





審核編輯:劉清

聲明:本文內容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權轉載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學習之用,如有內容侵權或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • 服務器
    +關注

    關注

    12

    文章

    8965

    瀏覽量

    85087

原文標題:分布式 Session 解決方案

文章出處:【微信號:magedu-Linux,微信公眾號:馬哥Linux運維】歡迎添加關注!文章轉載請注明出處。

收藏 人收藏

    評論

    相關推薦

    一致性測試系統(tǒng)的技術原理和也應用場景

    種有效手段。 綜上所述,一致性測試系統(tǒng)的技術原理和應用場景都非常廣泛和深入,在通信協(xié)議、網(wǎng)絡設備和系統(tǒng)的驗證以及企業(yè)系統(tǒng)數(shù)據(jù)校驗等方面發(fā)揮著重要作用。
    發(fā)表于 11-01 15:35

    行代碼,保障分布式事務一致性—GTS:微服務架構下分布式事務解決方案

    解決方案----GTS。該方案中提到的GTS是目前業(yè)界第款,也是唯款通用的解決微服務分布式事務問題的中間件,而且可以保證數(shù)據(jù)的強一致性
    發(fā)表于 06-05 19:14

    一致性規(guī)劃研究

    針對一致性規(guī)劃的高度求解復雜度,分析主流一致性規(guī)劃器的求解策略,給出影響一致性規(guī)劃器性能的主要因素:啟發(fā)信息的有效,信念狀態(tài)表示方法的緊湊
    發(fā)表于 04-06 08:43 ?12次下載

    藍鯨集群文件系統(tǒng)中資源交互一致性協(xié)議

    在藍鯨集群文件系統(tǒng)中,分布式資源交互在系統(tǒng)異常的情況下會出現(xiàn)資源狀態(tài)不一致的情況,為解決這問題,該文提出分布式資源交互一致性協(xié)議S2PC-
    發(fā)表于 04-21 09:24 ?12次下載

    一致性新型鎖同步機制的實現(xiàn)

    一致性新型鎖同步機制的實現(xiàn)將軟件分布式共享存儲系統(tǒng)所使用的基于域一致性協(xié)議鎖機制以新的方式加以實現(xiàn)。它充分利用SMP 結構所具有的特點,以多級方式實現(xiàn)鎖同步機制
    發(fā)表于 09-02 10:27 ?12次下載

    DBA迅速解決分布式事務XA一致性問題

    DBA迅速解決分布式事務XA一致性問題
    發(fā)表于 09-07 14:45 ?3次下載
    DBA迅速解決<b class='flag-5'>分布式</b>事務XA<b class='flag-5'>一致性</b>問題

    分布式一致性算法Yac

    傳統(tǒng)靜態(tài)拓撲主從模型分布式一致性算法存在嚴重負載不均及單點性能瓶頸效應,且崩潰節(jié)點大于集群規(guī)模的50qo時算法無法正常工作。針對上述問題,提出基于動態(tài)拓撲及有限表決思想的分布式一致性
    發(fā)表于 11-27 17:49 ?0次下載
    <b class='flag-5'>分布式</b><b class='flag-5'>一致性</b>算法Yac

    基于消息通信的分布式系統(tǒng)最終一致性平臺

    分布式系統(tǒng)中為了滿足高性能和吞吐量,般采用異步消息通信方式,但消息通信沒有解決分布式事務不一致問題。針對這個問題,提出建立一致性保障平臺
    發(fā)表于 12-04 16:15 ?0次下載
    基于消息通信的<b class='flag-5'>分布式</b>系統(tǒng)最終<b class='flag-5'>一致性</b>平臺

    分布式大數(shù)據(jù)不一致性檢測

    不高;而分布式環(huán)境下不一致性檢測更富有挑戰(zhàn),不僅需要考慮數(shù)據(jù)的遷移,檢測任務如何分配也是個難題.在大數(shù)據(jù)背景下,上述問題更加突出.提出了
    發(fā)表于 01-12 16:29 ?0次下載

    一致性哈希是什么?為什么它是可擴展的分布式系統(tǒng)架構的個必要工具

    在本文中,我們將了解一致性哈希是什么、為什么它是可擴展的分布式系統(tǒng)架構中的個必要工具。
    的頭像 發(fā)表于 07-17 17:57 ?4355次閱讀

    基于自觸發(fā)一致性算法的分布式分層控制策略

    針對傳統(tǒng)下垂控制及線路阻抗不匹配等因素引起的孤島微電網(wǎng)電壓偏差及無功功率難以均分的問題,提出基于自觸發(fā)一致性算法的分布式分層控制策略。在微電網(wǎng)二次控制層采用一致性算法構造電壓、無功功率全局平均值估計
    發(fā)表于 03-24 15:35 ?9次下載
    基于自觸發(fā)<b class='flag-5'>一致性</b>算法的<b class='flag-5'>分布式</b>分層控制策略

    種更安全的分布式一致性算法選舉機制

    目前應用于分布式系統(tǒng)中的基于選舉的分布式一致性算法(類 Paxos算法),都是采用得到50%以上選票者當選 Leader的方式進行選舉。此種選舉機制類似現(xiàn)實生活中的選舉,存在因控制投票而喪失系統(tǒng)去
    發(fā)表于 04-07 10:29 ?9次下載
    <b class='flag-5'>一</b>種更安全的<b class='flag-5'>分布式</b><b class='flag-5'>一致性</b>算法選舉機制

    最終一致性是現(xiàn)在大部分高可用的分布式系統(tǒng)的核心思路

    這篇文章我們聊分布式相關的內容。 提到分布式系統(tǒng),就定繞不開“一致性”,這次我們說說:最終一致性。 最終
    的頭像 發(fā)表于 06-17 14:40 ?1847次閱讀

    為什么需要分布式共識算法

    滿足CAP理論,而 分布式共識算法解決的就是CAP理論中的一致性問題。整個一致性問題分為三種問題: 順序一致性 線性一致性 因果
    的頭像 發(fā)表于 11-10 10:18 ?513次閱讀
    為什么需要<b class='flag-5'>分布式</b>共識算法

    分布式系統(tǒng)中常見的一致性模型

    什么是一致性模型? 在分布式系統(tǒng)中,C(一致性) 和 A(可用)始終存在矛盾。若想保證可用,就必須通過復制、分片等方式冗余存儲。而
    的頭像 發(fā)表于 11-10 11:33 ?854次閱讀
    <b class='flag-5'>分布式</b>系統(tǒng)中常見的<b class='flag-5'>一致性</b>模型