Java分布式session存儲(chǔ)解決方案圖解
前言
本文主要探討集群后不同Web服務(wù)器獲取Session數(shù)據(jù)的問題解決方案。
Session Stick
Session Stick 方案即將客戶端的每次請(qǐng)求都轉(zhuǎn)發(fā)至同一臺(tái)服務(wù)器,這就需要負(fù)載均衡器能夠根據(jù)每次請(qǐng)求的會(huì)話標(biāo)識(shí)(SessionId)來(lái)進(jìn)行請(qǐng)求轉(zhuǎn)發(fā),如下圖所示。
這種方案實(shí)現(xiàn)比較簡(jiǎn)單,對(duì)于Web服務(wù)器來(lái)說和單機(jī)的情況一樣。但是可能會(huì)帶來(lái)如下問題:
如果有一臺(tái)服務(wù)器宕機(jī)或者重啟,那么這臺(tái)機(jī)器上的會(huì)話數(shù)據(jù)會(huì)全部丟失。
會(huì)話標(biāo)識(shí)是應(yīng)用層信息,那么負(fù)載均衡要將同一個(gè)會(huì)話的請(qǐng)求都保存到同一個(gè)Web服務(wù)器上的話,就需要進(jìn)行應(yīng)用層(第7層)的解析,這個(gè)開銷比第4層大。
負(fù)載均衡器將變成一個(gè)有狀態(tài)的節(jié)點(diǎn),要將會(huì)話保存到具體Web服務(wù)器的映射。和無(wú)狀態(tài)節(jié)點(diǎn)相比,內(nèi)存消耗更大,容災(zāi)方面也會(huì)更麻煩。
Session Replication
Session Replication 的方案則不對(duì)負(fù)載均衡器做更改,而是在Web服務(wù)器之間增加了會(huì)話數(shù)據(jù)同步的功能,各個(gè)服務(wù)器之間通過同步保證不同Web服務(wù)器之間的Session數(shù)據(jù)的一致性,如下圖所示。
Session Replication 方案對(duì)負(fù)載均衡器不再有要求,但是同樣會(huì)帶來(lái)以下問題:
同步Session數(shù)據(jù)會(huì)造成額外的網(wǎng)絡(luò)帶寬的開銷,只要Session數(shù)據(jù)有變化,就需要將新產(chǎn)生的Session數(shù)據(jù)同步到其他服務(wù)器上,服務(wù)器數(shù)量越多,同步帶來(lái)的網(wǎng)絡(luò)帶寬開銷也就越大。
每臺(tái)Web服務(wù)器都需要保存全部的Session數(shù)據(jù),如果整個(gè)集群的Session數(shù)量太多的話,則對(duì)于每臺(tái)機(jī)器用于保存Session數(shù)據(jù)的占用會(huì)很嚴(yán)重。
Session 數(shù)據(jù)集中存儲(chǔ)
Session 數(shù)據(jù)集中存儲(chǔ)方案則是將集群中的所有Session集中存儲(chǔ)起來(lái),Web服務(wù)器本身則并不存儲(chǔ)Session數(shù)據(jù),不同的Web服務(wù)器從同樣的地方來(lái)獲取Session,如下圖所示。
相對(duì)于Session Replication方案,此方案的Session數(shù)據(jù)將不保存在本機(jī),并且Web服務(wù)器之間也沒有了Session數(shù)據(jù)的復(fù)制,但是該方案存在的問題在于:
讀寫Session數(shù)據(jù)引入了網(wǎng)絡(luò)操作,這相對(duì)于本機(jī)的數(shù)據(jù)讀取來(lái)說,問題就在于存在時(shí)延和不穩(wěn)定性,但是通信發(fā)生在內(nèi)網(wǎng),則問題不大。
如果集中存儲(chǔ)Session的機(jī)器或集群出現(xiàn)問題,則會(huì)影響應(yīng)用。
Cookie Based
Cookie Based 方案是將Session數(shù)據(jù)放在Cookie里,訪問Web服務(wù)器的時(shí)候,再由Web服務(wù)器生成對(duì)應(yīng)的Session數(shù)據(jù),如下圖所示。
但是Cookie Based 方案依然存在不足:
Cookie長(zhǎng)度的限制。這會(huì)導(dǎo)致Session長(zhǎng)度的限制。
安全性。Seesion數(shù)據(jù)本來(lái)是服務(wù)端數(shù)據(jù),卻被保存在了客戶端,即使可以加密,但是依然存在不安全性。
帶寬消耗。這里不是指內(nèi)部Web服務(wù)器之間的寬帶消耗,而是數(shù)據(jù)中心的整體外部帶寬的消耗。
性能影響。每次HTTP請(qǐng)求和響應(yīng)都帶有Seesion數(shù)據(jù),對(duì)Web服務(wù)器來(lái)說,在同樣的處理情況下,響應(yīng)的結(jié)果輸出越少,支持的并發(fā)就會(huì)越高。
總結(jié)
前面四個(gè)方案都是可行的,但是對(duì)于大型網(wǎng)站來(lái)說,Session Sticky和Session數(shù)據(jù)集中存儲(chǔ)是比較好的方案。
以上就是本文的全部?jī)?nèi)容,希望對(duì)大家的學(xué)習(xí)有所幫助,也希望大家多多支持好吧啦網(wǎng)。
相關(guān)文章:
1. .NET SkiaSharp 生成二維碼驗(yàn)證碼及指定區(qū)域截取方法實(shí)現(xiàn)2. idea設(shè)置提示不區(qū)分大小寫的方法3. HTTP協(xié)議常用的請(qǐng)求頭和響應(yīng)頭響應(yīng)詳解說明(學(xué)習(xí))4. css代碼優(yōu)化的12個(gè)技巧5. ASP.NET MVC通過勾選checkbox更改select的內(nèi)容6. 原生JS實(shí)現(xiàn)記憶翻牌游戲7. CentOS郵件服務(wù)器搭建系列—— POP / IMAP 服務(wù)器的構(gòu)建( Dovecot )8. Django使用HTTP協(xié)議向服務(wù)器傳參方式小結(jié)9. django創(chuàng)建css文件夾的具體方法10. IntelliJ IDEA創(chuàng)建web項(xiàng)目的方法
