457
大型網站之分布式會話管理
隨著網站的功能和用戶越來越多，單機器服務部署的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種方案都各有優劣，需要根據具體的實際場景做出合適的選擇。
原創文章轉載請注明出處：大型網站之分布式會話管理
最後更新：2017-05-22 11:02:02