Session 複製

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

• 優點：程式碼上不需要做支援和修改。
• 缺點：需要依賴支援的 Web 伺服器，一旦更換成不支援的 Web 伺服器就不能使用了，在資料量很大的情況下不僅佔用網路資源，而且會導致延遲。
• 適用場景：只適用於Web伺服器比較少且 Session 資料量少的情況。
• 可用方案：開源方案 tomcat-redis-session-manager，暫不支援 Tomcat8。

Session 粘滯

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

• 優點：使用簡單，沒有額外開銷。
• 缺點：一旦某個 Web 伺服器重啟或宕機，相對應的 Session 資料將會丟失，而且需要依賴負載均衡機制。
• 適用場景：對穩定性要求不是很高的業務情景。

Session 集中管理

在單獨的伺服器或伺服器叢集上使用快取技術，如 Redis 儲存 Session 資料，集中管理所有的 Session，所有的Web伺服器都從這個儲存介質中存取對應的 Session，實現 Session 共享。

• 優點：可靠性高，減少 Web 伺服器的資源開銷。
• 缺點：實現上有些複雜，配置較多。
• 適用場景：Web伺服器較多、要求高可用性的情況。
• 可用方案：開源方案 Spring Session，也可以自己實現，主要是重寫HttpServletRequestWrapper 中的 getSession 方法。

基於 Cookie 管理

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

• 優點：不需要依賴額外外部儲存，不需要額外配置。
• 缺點：不安全，易被盜取或篡改；Cookie 數量和長度有限制，需要消耗更多網路頻寬。
• 適用場景：資料不重要、不敏感且資料量小的情況。

總結

這四種方式，相對來說，Session 集中管理