創(chuàng)新互聯(lián)www.cdcxhl.cn八線動態(tài)BGP香港云服務(wù)器提供商，新人活動買多久送多久，劃算不套路！

成都創(chuàng)新互聯(lián)堅(jiān)持“要么做到，要么別承諾”的工作理念，服務(wù)領(lǐng)域包括：網(wǎng)站設(shè)計(jì)、成都網(wǎng)站建設(shè)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣等服務(wù)，滿足客戶于互聯(lián)網(wǎng)時(shí)代的達(dá)川網(wǎng)站設(shè)計(jì)、移動媒體設(shè)計(jì)的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴！

這篇文章主要為大家展示了如何運(yùn)用Java分布式session存儲，內(nèi)容簡而易懂，下面讓小編帶大家一起學(xué)習(xí)一下吧。

Session Stick

Session Stick 方案即將客戶端的每次請求都轉(zhuǎn)發(fā)至同一臺服務(wù)器，這就需要負(fù)載均衡器能夠根據(jù)每次請求的會話標(biāo)識（SessionId）來進(jìn)行請求轉(zhuǎn)發(fā)，如下圖所示。

這種方案實(shí)現(xiàn)比較簡單，對于Web服務(wù)器來說和單機(jī)的情況一樣。但是可能會帶來如下問題：

如果有一臺服務(wù)器宕機(jī)或者重啟，那么這臺機(jī)器上的會話數(shù)據(jù)會全部丟失。

會話標(biāo)識是應(yīng)用層信息，那么負(fù)載均衡要將同一個(gè)會話的請求都保存到同一個(gè)Web服務(wù)器上的話，就需要進(jìn)行應(yīng)用層（第7層）的解析，這個(gè)開銷比第4層大。

負(fù)載均衡器將變成一個(gè)有狀態(tài)的節(jié)點(diǎn)，要將會話保存到具體Web服務(wù)器的映射。和無狀態(tài)節(jié)點(diǎn)相比，內(nèi)存消耗更大，容災(zāi)方面也會更麻煩。

Session Replication

Session Replication 的方案則不對負(fù)載均衡器做更改，而是在Web服務(wù)器之間增加了會話數(shù)據(jù)同步的功能，各個(gè)服務(wù)器之間通過同步保證不同Web服務(wù)器之間的Session數(shù)據(jù)的一致性，如下圖所示。

Session Replication 方案對負(fù)載均衡器不再有要求，但是同樣會帶來以下問題：

同步Session數(shù)據(jù)會造成額外的網(wǎng)絡(luò)帶寬的開銷，只要Session數(shù)據(jù)有變化，就需要將新產(chǎn)生的Session數(shù)據(jù)同步到其他服務(wù)器上，服務(wù)器數(shù)量越多，同步帶來的網(wǎng)絡(luò)帶寬開銷也就越大。

每臺Web服務(wù)器都需要保存全部的Session數(shù)據(jù)，如果整個(gè)集群的Session數(shù)量太多的話，則對于每臺機(jī)器用于保存Session數(shù)據(jù)的占用會很嚴(yán)重。

Session 數(shù)據(jù)集中存儲

Session 數(shù)據(jù)集中存儲方案則是將集群中的所有Session集中存儲起來，Web服務(wù)器本身則并不存儲Session數(shù)據(jù)，不同的Web服務(wù)器從同樣的地方來獲取Session，如下圖所示。

相對于Session Replication方案，此方案的Session數(shù)據(jù)將不保存在本機(jī)，并且Web服務(wù)器之間也沒有了Session數(shù)據(jù)的復(fù)制，但是該方案存在的問題在于：

讀寫Session數(shù)據(jù)引入了網(wǎng)絡(luò)操作，這相對于本機(jī)的數(shù)據(jù)讀取來說，問題就在于存在時(shí)延和不穩(wěn)定性，但是通信發(fā)生在內(nèi)網(wǎng)，則問題不大。

如果集中存儲Session的機(jī)器或集群出現(xiàn)問題，則會影響應(yīng)用。

Cookie Based

Cookie Based 方案是將Session數(shù)據(jù)放在Cookie里，訪問Web服務(wù)器的時(shí)候，再由Web服務(wù)器生成對應(yīng)的Session數(shù)據(jù)，如下圖所示。

但是Cookie Based 方案依然存在不足：

Cookie長度的限制。這會導(dǎo)致Session長度的限制。

安全性。Seesion數(shù)據(jù)本來是服務(wù)端數(shù)據(jù)，卻被保存在了客戶端，即使可以加密，但是依然存在不安全性。

帶寬消耗。這里不是指內(nèi)部Web服務(wù)器之間的寬帶消耗，而是數(shù)據(jù)中心的整體外部帶寬的消耗。

性能影響。每次HTTP請求和響應(yīng)都帶有Seesion數(shù)據(jù)，對Web服務(wù)器來說，在同樣的處理情況下，響應(yīng)的結(jié)果輸出越少，支持的并發(fā)就會越高。

以上就是關(guān)于如何運(yùn)用Java分布式session存儲的內(nèi)容，如果你們有學(xué)習(xí)到知識或者技能，可以把它分享出去讓更多的人看到。

分享標(biāo)題：如何運(yùn)用Java分布式session存儲-創(chuàng)新互聯(lián)
文章鏈接：http://weahome.cn/article/csjshe.html