Java分散式session儲存解決方案圖解
前言
本文主要探討集群后不同Web伺服器獲取Session資料的問題解決方案。
Session Stick
Session Stick 方案即將客戶端的每次請求都轉發至同一臺伺服器,這就需要負載均衡器能夠根據每次請求的會話標識(SessionId)來進行請求轉發,如下圖所示。
這種方案實現比較簡單,對於Web伺服器來說和單機的情況一樣。但是可能會帶來如下問題:
如果有一臺伺服器宕機或者重啟,那麼這臺機器上的會話資料會全部丟失。
會話標識是應用層資訊,那麼負載均衡要將同一個會話的請求都儲存到同一個Web伺服器上的話,就需要進行應用層(第7層)的解析,這個開銷比第4層大。
負載均衡器將變成一個有狀態的節點,要將會話儲存到具體Web伺服器的對映。和無狀態節點相比,記憶體消耗更大,容災方面也會更麻煩。
Session Replication
Session Replication 的方案則不對負載均衡器做更改,而是在Web伺服器之間增加了會話資料同步的功能,各個伺服器之間通過同步保證不同Web伺服器之間的Session資料的一致性,如下圖所示。
Session Replication 方案對負載均衡器不再有要求,但是同樣會帶來以下問題:
同步Session資料會造成額外的網路頻寬的開銷,只要Session資料有變化,就需要將新產生的Session資料同步到其他伺服器上,伺服器數量越多,同步帶來的網路頻寬開銷也就越大。
每臺Web伺服器都需要儲存全部的Session資料,如果整個叢集的Session數量太多的話,則對於每臺機器用於儲存Session資料的佔用會很嚴重。
Session 資料集中儲存
Session 資料集中儲存方案則是將叢集中的所有Session集中儲存起來,Web伺服器本身則並不儲存Session資料,不同的Web伺服器從同樣的地方來獲取Session,如下圖所示。
相對於Session Replication方案,此方案的Session資料將不儲存在本機,並且Web伺服器之間也沒有了Session資料的複製,但是該方案存在的問題在於:
讀寫Session資料引入了網路操作,這相對於本機的資料讀取來說,問題就在於存在時延和不穩定性,但是通訊發生在內網,則問題不大。
如果集中儲存Session的機器或叢集出現問題,則會影響應用。
Cookie Based
Cookie Based 方案是將Session資料放在Cookie裡,訪問Web伺服器的時候,再由Web伺服器生成對應的Session資料,如下圖所示。
但是Cookie Based 方案依然存在不足:
Cookie長度的限制。這會導致Session長度的限制。
安全性。Seesion資料本來是服務端資料,卻被儲存在了客戶端,即使可以加密,但是依然存在不安全性。
頻寬消耗。這裡不是指內部Web伺服器之間的寬頻消耗,而是資料中心的整體外部頻寬的消耗。
效能影響。每次HTTP請求和響應都帶有Seesion資料,對Web伺服器來說,在同樣的處理情況下,響應的結果輸出越少,支援的併發就會越高。
總結
前面四個方案都是可行的,但是對於大型網站來說,Session Sticky和Session資料集中儲存是比較好的方案。
以上就是本文的全部內容,希望對大家的學習有所幫助,也希望大家多多支援我們。