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

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

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

具體的問題

當一個帶有會話表示的Http請求到Web服務器後，需求在請求中的處理過程當中找到session數據。而問題就在於，session是保存在單機上的。 假設咱們有應用A和應用B，如今一位用戶第一次訪問網站，session數據保存在應用A中。若是咱們不作處理，怎麼保障接下來的請求每次都請求到應用A呢? 如請求到了應用B中，就會發現沒有這位用戶的session數據，這絕對是不能容忍的。

解決方案

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

Session Stick

在單機狀況，session保存在單機上，請求也是到這臺單機上，不會有問題。變成多臺後，若是能保障每次請求都到同一臺服務，那就和單機同樣了。 這須要在負載均衡設備上修改。這就是Session Stick，這種方式也會有問題：

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

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

Session複製

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

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

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

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

Session集中管理

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

• 讀寫session引入了網絡操做，相對於本機讀寫session，帶來了延時和不穩定性。

• 如Session集中服務有問題，會影響應用。

基於Cookie管理

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

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

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

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

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

總結

這4種方案都是可用的方案，我比較傾向於使用Session集中管理，不過這4種方案都各有優劣，須要根據具體的實際場景作出合適的選擇。