大型網站之分散式會話管理
隨著網站的功能和使用者越來越多,單機器服務部署的Web應用已經不能再支援了。這時候就需要優化或調整目前的架構,具體怎麼優化,或先優化哪部分,這取決於網站的具體情況, 並非總是一個套路。
如根據使用情況得知,資料庫壓力大,則就可以先設施讀寫分離,分庫分表,是垂直劃分(可以簡單的理解為按業務功能劃分), 還是水平劃分(如使用者表資料量很多,就可以按一定的規則分表設計,表結構仍然是相同的)。如Web應用伺服器壓力大,可以增加一臺服務部署應用, 即從單臺服務變為叢集。變為叢集后,使用者訪問網站,到底是選擇哪一臺伺服器呢?這就需要在應用伺服器前增加負載均衡裝置來解決。還有點就是會話session 管理的問題,接下來會詳細說明這問題。
具體的問題
當一個帶有會話表示的Http請求到Web伺服器後,需求在請求中的處理過程中找到session資料。而問題就在於,session是儲存在單機上的。 假設我們有應用A和應用B,現在一位使用者第一次訪問網站,session資料儲存在應用A中。如果我們不做處理,怎麼保障接下來的請求每次都請求到應用A呢? 如請求到了應用B中,就會發現沒有這位使用者的session資料,這絕對是不能容忍的。
解決方案
解決方案有Session Stick,Session複製,Session集中管理,基於Cookie管理,下面一一說明。
1 Session Stick
在單機情況,session儲存在單機上,請求也是到這臺單機上,不會有問題。變成多臺後,如果能保障每次請求都到同一臺服務,那就和單機一樣了。 這需要在負載均衡裝置上修改。這就是Session Stick,這種方式也會有問題:
- 如果某一臺伺服器當機或重啟,那麼這臺伺服器上的session資料就丟失了。如果session資料中還有登入狀態資訊,那麼使用者需要重現登入。
- 負載均衡要處理具體的session到伺服器的對映。
2 Session複製
Session複製顧名思義,就是每臺應用服務,都儲存會話session資料,一般的應用容器都支援。與Session Stick相比,sessioon複製對負載均衡 沒有太多的要求。不過這個方案還是有缺點:
- 同步session資料帶來都網路開銷。只要session資料變化,就需要同步到所有機器上,機器越多,網路開銷越大。
- 由於每臺伺服器都儲存session資料,如果叢集的session資料很多,比如90萬人在訪問網站,每臺機器用於儲存session資料的內容佔用很嚴重。
這就是Session複製,這個方案是靠應用容器來完成,並不依賴應用,如果應用服務數量並不是很多,可以考慮。
3 Session集中管理
這個也很好理解,再加一臺服務,專門來管理session資料,每臺應用服務都從專門的session管理服務中取會話session資料。可以使用資料庫,NOSQL資料庫等。 和Session複製相比,減少了每臺應用服務的記憶體使用,同步session帶來的網路開銷問題。但還是有缺點:
- 讀寫session引入了網路操作,相對於本機讀寫session,帶來了延時和不穩定性。如Session集中服務有問題,會影響應用。
4 基於Cookie管理
最後一個是基於Cookie管理,我們把session資料存放在cookie中,然後請求過來後,從cookie中獲取session資料。與集中管理相比,這個方案並不依賴外部 的儲存系統,讀寫session資料帶來的網路操作延時和不穩定性。但依然有缺點:
- Cookie有長度限制,這會影響session資料的長度。
- 安全性。session資料本來儲存在服務端的,而這個方案是讓session資料轉到外部網路或客戶端中,所以會有安全性問題。不過可以對寫入Cookie的session
資料做加密。 - 頻寬消耗。由於加了session資料,頻寬當然也會增加一點。
- 效能消耗。每次Http請求和響應都帶有Session資料,對於Web伺服器來說,在同樣的處理情況下,響應的結果輸出越少,支援的併發請求越多。
總結
這4種方案都是可用的方案,我比較傾向於使用Session集中管理,不過這4種方案都各有優劣,需要根據具體的實際場景做出合適的選擇。
轉載自:大型網站之分散式會話管理
相關文章
- 大型網站為何要打造分散式服務網站分散式
- 大型分散式網站架構技術總結分散式網站架構
- 大型分散式網站架構實戰專案分析分散式網站架構
- 大型分散式網站架構:快取在分散式系統中的應用分散式網站架構快取
- 理解大型分散式網站你應該知道這些概念分散式網站
- 理解大型分散式網站你必須知道這些概念分散式網站
- 大型網站架構系列:分散式訊息佇列(一)網站架構分散式佇列
- 我也要談談大型網站架構之系列(4)——分散式中的非同步通訊網站架構分散式非同步
- 使用Redis實現分散式會話Redis分散式會話
- 大型分散式團隊的程式碼版本管理分散式
- 大型網站架構之我見網站架構
- 分散式爬蟲的部署之Gerapy分散式管理分散式爬蟲
- 會話管理會話
- 大型網站技術架構(二)--大型網站架構演化網站架構
- 大型網站技術架構(一)--大型網站架構演化網站架構
- 大型網站架構網站架構
- CMS大型入口網站網站
- 淺談大型網站之負載均衡架構網站負載架構
- 如何對網站進行管理 —修改電話網站
- 【轉載】大型網站效能網站
- 大型網站架構演化網站架構
- 如何開發大型網站網站
- 分散式網站架構學習資源分散式網站架構
- Spring Cloud大型網際網路分散式企業微服務雲架構SpringCloud分散式微服務架構
- dubbo+zookeeper+springmvc+mybatis分散式大型網際網路企業架構SpringMVCMyBatis分散式架構
- 漫談大型網站架構網站架構
- PHP在大型網站開發PHP網站
- 大型網路遊戲和大型網站需要伺服器的不同遊戲網站伺服器
- 大白話聊聊分散式事務分散式
- 分散式之抉擇分散式鎖分散式
- 關於SpringCloud大型網際網路分散式企業微服務雲架構SpringGCCloud分散式微服務架構
- 學會用資料說話-分散式鎖究竟可以多少併發?分散式
- 大型分散式系統現場,阿里大牛帶你實戰分散式系統分散式阿里
- 大型網站架構系列:電商網站架構案例(1)網站架構
- 大型網站架構系列:電商網站架構案例(2)網站架構
- 大型網站架構系列:電商網站架構案例(3)網站架構
- 網站提示:”會話目錄寫入許可權不足“網站會話
- #魔術方法(會話管理)會話