分佈式Session管理的必要性

Web應用在單機部署的情況下，Session是被單個應用服務器存儲管理的，由於只有一個應用服務器，用戶的所有請求都是通過它進行響應處理的，所以能夠很容易實現會話跟蹤和保持。隨著業務量的增長，系統架構需要做出調整以適應發展的需要，可能會使用分佈式架構或微服務架構，無論使用哪種架構方式，應用系統單機部署的模式已經不能滿足需求，所以會將應用系統部署到多臺應用服務器上，用戶的請求也會通過負載均衡轉發到某個具體應用服務器上執行，可能會出現在A1系統登錄後創建並保存Session，再次發起請求，請求被轉發到A2系統上顯示未登錄的情況，此時單機部署模式下的Session機制已不能滿足要求。所以，在分佈式架構或微服務架構下，必須保證一個應用服務器上保存Session後，其它應用服務器可以同步或共享這個Session。

分佈式session管理解決方案

分佈式Session有如下幾種實現方式。

1.Session複製機制

在支持Session複製的Web服務器上，通過修改Web服務器的配置，可以實現將Session同步到其它Web服務器上，達到每個Web服務器上都保存一致的Session。

優點：代碼上不需要做支持和修改。

缺點：需要依賴支持的Web服務器，一旦更換成不支持的Web服務器就不能使用了，在數據量很大的情況下不僅佔用網絡資源，而且會導致延遲。

適用場景：只適用於Web服務器比較少且Session數據量少的情況。

可用方案：開源方案tomcat-redis-session-manager，暫不支持Tomcat8。

2.Session粘滯機制

將用戶的每次請求都通過某種方法強制分發到某一個Web服務器上，只要這個Web服務器上存儲了對應Session數據，就可以實現會話跟蹤。

優點：使用簡單，沒有額外開銷。

缺點：一旦某個Web服務器重啟或宕機，相對應的Session數據將會丟失，而且需要依賴負載均衡機制。

適用場景：對穩定性要求不是很高的業務情景。

3.Session集中管理機制

在單獨的服務器或服務器集群上使用緩存技術，如Redis存儲Session數據，集中管理所有的Session，所有的Web服務器都從這個存儲介質中存取對應的Session，實現Session共享。

優點：可靠性高，減少Web服務器的資源開銷。

缺點：實現上有些複雜，配置較多。

適用場景：Web服務器較多、要求高可用性的情況。

可用方案：開源方案Spring Session，也可以自己實現，主要是重寫HttpServletRequestWrapper中的getSession方法，博主也動手寫了一個，github搜索joincat用戶，然後自取。

4.基於Cookie管理機制

這種方式每次發起請求的時候都需要將Session數據放到Cookie中傳遞給服務端。

優點：不需要依賴額外外部存儲，不需要額外配置。

缺點：不安全，易被盜取或篡改；Cookie數量和長度有限制，需要消耗更多網絡帶寬。

適用場景：數據不重要、不敏感且數據量小的情況。

最後的總結

以上四種方式，相對來說，Session集中管理更加可靠，使用也是最多的。