前言

本文主要探討集群后不同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數據集中存儲是比較好的方案。

以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持好吧啦網。