随着網站的功能和使用者越來越多,單機器服務部署的web應用已經不能再支援了。這時候就需要優化或調整目前的架構,具體怎麼優化,或先優化哪部分,這取決于網站的具體情況, 并非總是一個套路。
如根據使用情況得知,資料庫壓力大,則就可以先設施讀寫分離,分庫分表,是垂直劃分(可以簡單的了解為按業務功能劃分), 還是水準劃分(如使用者表資料量很多,就可以按一定的規則分表設計,表結構仍然是相同的)。如web應用伺服器壓力大,可以增加一台服務部署應用, 即從單台服務變為叢集。變為叢集後,使用者通路網站,到底是選擇哪一台伺服器呢?這就需要在應用伺服器前增加負載均衡裝置來解決。還有點就是會話session 管理的問題,接下來會詳細說明這問題。
當一個帶有會話表示的http請求到web伺服器後,需求在請求中的處理過程中找到session資料。而問題就在于,session是儲存在單機上的。 假設我們有應用a和應用b,現在一位使用者第一次通路網站,session資料儲存在應用a中。如果我們不做處理,怎麼保障接下來的請求每次都請求到應用a呢? 如請求到了應用b中,就會發現沒有這位使用者的session資料,這絕對是不能容忍的。
解決方案有session stick,session複制,session集中管理,基于cookie管理,下面一一說明。
在單機情況,session儲存在單機上,請求也是到這台單機上,不會有問題。變成多台後,如果能保障每次請求都到同一台服務,那就和單機一樣了。 這需要在負載均衡裝置上修改。這就是session stick,這種方式也會有問題:
如果某一台伺服器當機或重新開機,那麼這台伺服器上的session資料就丢失了。如果session資料中還有登入狀态資訊,那麼使用者需要重制登入。
負載均衡要處理具體的session到伺服器的映射。
session複制顧名思義,就是每台應用服務,都儲存會話session資料,一般的應用容器都支援。與session stick相比,sessioon複制對負載均衡 沒有太多的要求。不過這個方案還是有缺點:
同步session資料帶來都網絡開銷。隻要session資料變化,就需要同步到所有機器上,機器越多,網絡開銷越大。
由于每台伺服器都儲存session資料,如果叢集的session資料很多,比如90萬人在通路網站,每台機器用于儲存session資料的内容占用很嚴重。
這就是session複制,這個方案是靠應用容器來完成,并不依賴應用,如果應用服務數量并不是很多,可以考慮。
這個也很好了解,再加一台服務,專門來管理session資料,每台應用服務都從專門的session管理服務中取會話session資料。可以使用資料庫,nosql資料庫等。 和session複制相比,減少了每台應用服務的記憶體使用,同步session帶來的網絡開銷問題。但還是有缺點:
讀寫session引入了網絡操作,相對于本機讀寫session,帶來了延時和不穩定性。
如session集中服務有問題,會影響應用。
最後一個是基于cookie管理,我們把session資料存放在cookie中,然後請求過來後,從cookie中擷取session資料。與集中管理相比,這個方案并不依賴外部 的存儲系統,讀寫session資料帶來的網絡操作延時和不穩定性。但依然有缺點:
cookie有長度限制,這會影響session資料的長度。
安全性。session資料本來存儲在服務端的,而這個方案是讓session資料轉到外部網絡或用戶端中,是以會有安全性問題。不過可以對寫入cookie的session 資料做加密。
帶寬消耗。由于加了session資料,帶寬當然也會增加一點。
性能消耗。每次http請求和響應都帶有session資料,對于web伺服器來說,在同樣的處理情況下,響應的結果輸出越少,支援的并發請求越多。
這4種方案都是可用的方案,我比較傾向于使用session集中管理,不過這4種方案都各有優劣,需要根據具體的實際場景做出合适的選擇。