掃二維碼與項(xiàng)目經(jīng)理溝通
我們?cè)谖⑿派?4小時(shí)期待你的聲音
解答本文疑問(wèn)/技術(shù)咨詢/運(yùn)營(yíng)咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流
分布式架構(gòu)下的session共享,也可以稱作分布式session一致性;關(guān)于這個(gè)問(wèn)題,和大家說(shuō)一說(shuō)解決方案(如果有其他的方案,可以留言討論)。

如果大家做過(guò)web應(yīng)用開(kāi)發(fā)的話,應(yīng)該對(duì)session比較熟悉;服務(wù)器會(huì)為每個(gè)用戶創(chuàng)建一個(gè)會(huì)話,存儲(chǔ)用戶的相關(guān)信息,以便在后面的請(qǐng)求中,可以夠定位到同一個(gè)上下文。
例如用戶在登錄之后,再進(jìn)行頁(yè)面跳轉(zhuǎn)的時(shí)候,存儲(chǔ)在session中的信息會(huì)一直保持,如果用戶還沒(méi)有session,那么服務(wù)器會(huì)創(chuàng)建一個(gè)session對(duì)象,直到會(huì)話過(guò)期或主動(dòng)放棄后(退出),服務(wù)器才會(huì)把session終止掉。
在N年前,那個(gè)都是單個(gè)服務(wù)器的年代,session直接保存在服務(wù)器中,是一點(diǎn)問(wèn)題沒(méi)有的,而且實(shí)現(xiàn)起來(lái)很容易。
但是隨著分布式架構(gòu)的流行,單個(gè)服務(wù)器已經(jīng)不能滿足系統(tǒng)的需要了,通常都會(huì)把系統(tǒng)部署在多臺(tái)服務(wù)器上,通過(guò)負(fù)載均衡把請(qǐng)求分發(fā)到其中的一臺(tái)服務(wù)器上,這樣很可能同一個(gè)用戶的請(qǐng)求被分發(fā)到不同的服務(wù)器上,因?yàn)閟ession是保存在服務(wù)器上的,那么很有可能第一次請(qǐng)求訪問(wèn)的A服務(wù)器,創(chuàng)建了session,但是第二次訪問(wèn)到了B服務(wù)器,這時(shí)就會(huì)出現(xiàn)取不到session的情況。
于是,分布式架構(gòu)中,session共享就成了一個(gè)很大的問(wèn)題。
可以參考以下四種方式,具體采用那種根據(jù)實(shí)際項(xiàng)目情況做一個(gè)權(quán)衡 :
1.Session sticky(粘性):
思路就是某一個(gè)用戶第一次登陸時(shí)session保存到哪個(gè)地方,第二次訪問(wèn)時(shí)還去哪個(gè)服務(wù)器找。
2.Session Relication(復(fù)制):
為每臺(tái)應(yīng)用服務(wù)器都保存一份session數(shù)據(jù),適用于機(jī)器比較少的情況
3.Session 共享:
將session數(shù)據(jù)集中保存,所有的應(yīng)用服務(wù)器都來(lái)訪問(wèn)這個(gè)session共享服務(wù)器
4.cookie Base:
session數(shù)據(jù)存放在cookie中,然后在應(yīng)用服務(wù)器從cookies中生成對(duì)應(yīng)的session數(shù)據(jù),但是會(huì)有安全性的問(wèn)題
到此,以上就是小編對(duì)于的問(wèn)題就介紹到這了,希望這1點(diǎn)解答對(duì)大家有用。

我們?cè)谖⑿派?4小時(shí)期待你的聲音
解答本文疑問(wèn)/技術(shù)咨詢/運(yùn)營(yíng)咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流