大型網站之分佈式會話管理

隨着網站的功能和用戶愈來愈多，單機器服務部署的Web應用已經不能再支持了。這時候就須要優化或調整架構，具體怎麼優化，或先優化哪部分，這取決於網站的具體狀況， 並不是老是一個套路。

如根據使用狀況得知，數據庫壓力大，則就能夠先設施讀寫分離，分庫分表，是垂直劃分（按業務劃分）， 仍是水平劃分（如用戶表數據量不少，能夠按必定規則分表設計，表結構仍然相同)。如 Web 應用服務器壓力大，能夠增長一臺服務部署應用， 即從單臺服務變爲集羣。變爲集羣后，用戶訪問網站，究竟是選擇哪一臺服務器呢？這就須要在應用服務器前增長負載均衡設備來解決。還有點就是會話 session 管理的問題，接下來會詳細說明這問題。

具體的問題

---

當一個帶有會話的 Http 請求到達 Web 服務器後，須要在請求中的處理 session 數據。問題在於，session 是保存在單機上的。假設咱們是一個分佈式集羣，有應用 A 和應用 B，A 和 B 可能位於不一樣的服務器（集羣），如今一位用戶第一次訪問網站，session 數據保存在應用 A 中。若是不作處理，怎麼保障接下來的請求每次都請求到應用 A 呢? 如接下來用戶又請求到了應用 B ，就會發現沒有這位用戶的 session 數據，這絕對是不能容忍的。

解決方案

---

解決方案有 Session Stick，Session 複製，Session 集中管理，基於 Cookie 管理，下面一一說明。

1，Session Stick

在單機狀況，session 保存在單機上，請求也是到這臺單機上，不會有問題。變成多臺（集羣，此時只是增長 Web 集羣，並無進行垂直劃分，每臺服務器具備相同的功能）後，若是能保障每次請求都到同一臺服務，那就和單機同樣了。 這須要在負載均衡設備上修改，保證用戶每次都落到同一臺服務器上。這就是 Session Stick，這種方式也會有問題：

• 若是某一臺服務器宕機或重啓，那麼這臺服務器上的 session 數據就丟失了。若是 session 數據中還有登陸狀態信息，那麼用戶須要從新登陸。

• 負載均衡要處理具體的 session 到服務器的映射。

2，Session 複製

Session 複製顧名思義，就是每臺應用服務，都保存會話 session 數據，通常的應用容器都支持。與 Session Stick 相比，sessioon 複製對負載均衡沒有太多的要求。不過該方案的缺點是：

• 同步 session 數據帶來都網絡開銷。只要 session 數據變化，就須要同步到全部機器上，機器越多，網絡開銷越大。

• 因爲每臺服務器都保存session數據，若是集羣的session數據不少，好比90萬人在訪問網站，每臺機器用於保存session數據的內容佔用很嚴重。

這個方案靠應用容器來完成，並不依賴應用，若是應用服務數量並非不少，能夠考慮。

3，Session 集中管理

這個也很好理解，用一臺專門的服務器管理 session 數據，每臺應用服務都從專門的 session 管理服務中取會話 session 數據。可使用數據庫，NOSQL 數據庫等。與 Session 複製相比，減小了每臺應用服務的內存使用，同步 session 帶來的網絡開銷問題。但缺點是：

• 讀寫session引入了網絡操做，相對於本機讀寫session，帶來了延時和不穩定性。如Session集中服務有問題，會影響應用。

4，基於 Cookie 管理

最後一個是基於 Cookie 管理，把 session 數據存放在 cookie 中，而後請求過來後，從cookie中獲取session數據。雖然與集中管理相比，這個方案並不依賴外部的存儲系統，讀寫 session 數據帶來的網絡操做延時和不穩定性，但用戶可能會禁用 Cookie。它的缺點是：

• Cookie有長度限制，這會影響session數據的長度。

• 安全性。session數據原本存儲在服務端的，而這個方案是讓session數據轉到外部網絡或客戶端中，因此會有安全性問題。不過能夠對寫入Cookie的session 數據作加密。

• 帶寬消耗。因爲加了session數據，帶寬固然也會增長一點。

• 性能消耗。每次Http請求和響應都帶有Session數據，對於Web服務器來講，在一樣的處理狀況下，響應的結果輸出越少，支持的併發請求越多。

總結

---

須要根據具體的實際場景作出合適的選擇。這四種方案都是可用的，我我的比較傾向集中管理。