Session會話管理

Web中的Session和Cookie回顧

1. Session機制

由于HTTP協議是無狀態的協議，一次瀏覽器和服務器的交互過程就是：

瀏覽器：你好嗎?

服務器：很好!

這就是一次會話，對話完成后，這次會話就結束了，服務器端并不能記住這個人，下次再對話時，服務器端并不知道是上一次的這個人，所以服務端需要記錄用戶的狀態時，就需要用某種機制來識別具體的用戶，這個機制就是Session。

2. Cookie

服務端如何識別特定的客戶?

這個時候需要使用Cookie。每次HTTP請求的時候，客戶端都會發送相應的Cookie信息到服務端。

實際上大多數的應用都是用 Cookie 來實現Session跟蹤的，第一次創建Session時，服務端會在HTTP協議中向客戶端 Cookie 中記錄一個Session ID，以后每次請求把這個會話ID發送到服務器，這樣服務端就知道客戶端是誰了。

3. url重寫

那么如果客戶端的瀏覽器禁用了 Cookie 怎么辦?

一般這種情況下，會使用一種叫做URL重寫的技術來進行session會話跟蹤，即每次HTTP交互，URL后面都會被附加上一個諸如 sessionId=xxxxx 這樣的參數，服務端據此來識別客戶端是誰。

在Web項目開發中，Session會話管理是一個很重要的部分，用于存儲與記錄用戶的狀態或相關的數據。

通常情況下session交由容器(tomcat)來負責存儲和管理，但是如果項目部署在多臺tomcat中，則session管理存在很大的問題；

多臺tomcat之間無法共享session，比如用戶在tomcat A服務器上已經登錄了，但當負載均衡跳轉到tomcat B時，由于tomcat B服務器并沒有用戶的登錄信息，session就失效了，用戶就退出了登錄；

 一旦tomcat容器關閉或重啟也會導致session會話失效；

因此如果項目部署在多臺tomcat中，就需要解決session共享的問題。

Session會話管理及帶來的問題

在Web項目開發中，Session會話管理是一個很重要的部分，用于存儲與記錄用戶的狀態或相關的數據。

通常情況下session交由容器（tomcat）來負責存儲和管理，但是如果項目部署在多臺tomcat中，則session管理存在很大的問題：

• 多臺tomcat之間無法共享session，比如用戶在tomcat A服務器上已經登錄了，但當負載均衡跳轉到tomcat B時，由于tomcat B服務器并沒有用戶的登錄信息，session就失效了，用戶就退出了登錄；

• 一旦tomcat容器關閉或重啟也會導致session會話失效；

因此如果項目部署在多臺tomcat中，就需要解決session共享的問題。

Session會話共享方案

第一種：是使用容器擴展插件來實現，比如基于Tomcat的tomcat-redis-session-manager插件，基于Jetty的jetty-session-redis插件、memcached-session-manager插件;這個方案的好處是對項目來說是透明的，無需改動代碼，但是由于過于依賴容器，一旦容器升級或者更換意味著又得重新配置；其實底層是，復制session到其它服務器，所以會有一定的延遲，也不能部署太多的服務器。

第二種：是使用Nginx負載均衡的ip_hash策略實現用戶每次訪問都綁定到同一臺具體的后臺tomcat服務器實現session總是存在這種方案的局限性是ip不能變，如果手機從北京跳到河北，那么ip會發生變化;另外負載均衡的時候，如果某一臺服務器發生故障，那么會重新定位，也會跳轉到別的機器。

第三種：是自己寫一套Session會話管理的工具類，在需要使用會話的時候都從自己的工具類中獲取，而工具類后端存儲可以放到Redis中，這個方案靈活性很好，但開發需要一些額外的時間。

第四種：是使用框架的會話管理工具，也就是我們要介紹的Spring session，這個方案既不依賴tomcat容器，又不需要改動代碼，由Spring session框架為我們提供，可以說是目前非常完美的session共享解決方案。