session同步（複製）l 優點(1) web-server（Tomcat）原生支援，只需要修改配置檔案l 缺點(1) session同步需要資料傳輸，佔用大量網路頻寬，降低了伺服器群的業務處理能力(2) 任意一臺web-server儲存的資料都是所有web-server的session總和，受到記憶體限制無法水平擴充套件更多的web-server。

(3) 大型分散式叢集情況下，由於所有web-server都全量儲存資料，所以此方案不可取。

Session 複製原理的解釋:

網路中有三種通訊模式:

(1) 單播

(2) 廣播

(3) 組播:地址 224.0.0.0 ~ 224.0.0.255 為使用者可用的組播地址

session資料儲存在客戶端cookiel 優點(1) 伺服器不需儲存session，使用者儲存自己的session資訊到cookie中。節省服務端資源l 缺點(1) 都是缺點，這只是一種思路。n 具體如下：(1) 每次http請求，攜帶使用者在cookie中的完整資訊，浪費網路頻寬(2) session資料放在cookie中，cookie有長度限制4K，不能儲存大量資訊(3) session資料放在cookie中，存在洩漏、篡改、竊取等安全隱患(4) 這種方式不會使用。 反向代理hash一致性原理：利用反向代理使得同一個使用者的請求落在一臺固定的伺服器上，不要發生伺服器切換即可，伺服器之前記憶體session中的資料還是在的；可以有兩種實現；3.1）、四層代理ip_hash原理：反向代理層使用使用者ip來做hash，以保證同一個ip的請求落在同一個web-server上3.2）、七層代理根據http協議任意業務欄位自定義hash原理：反向代理使用http協議中的某些業務屬性來做hash，例如sid，city_id，user_id等，能夠更加靈活的實施hash策略，以保證同一個瀏覽器使用者的請求落在同一個web-server上3.3）、優缺點優點：只需要改nginx配置，不需要修改應用程式碼負載均衡，只要hash屬性的值分佈是均勻的，多臺web-server的負載是均衡的可以支援web-server水平擴充套件（session同步法是不行的，受記憶體限制）缺點session還是存在web-server中的，所以web-server重啟可能導致部分session丟失，影響業務，如部分使用者需要重新登入如果web-server水平擴充套件，rehash後session重新分佈，也會有一部分使用者路由不到正確的session但是以上缺點問題也不是很大，因為session本來都是有有效期的。所以這兩種反向代理的方式可以使用後端統一儲存session資料原理：將session儲存在web-server後端的儲存層，資料庫或者快取；但是由於session是頻繁讀取的資料而且有過期時間，所以我們一般存在Redis快取中，而不是MySQL等dbl 優點：n 沒有安全隱患n 可以水平擴充套件，資料庫/快取水平切分即可n web-server重啟或者擴容都不會有session丟失l 不足n 增加了一次網路呼叫，並且需要修改應用程式碼；如將所有的getSession方法替換為從Redis查資料的方式 總結l 保證session一致性的架構設計常見方法：n session同步法：多臺web-server相互同步資料n 客戶端儲存法：一個使用者只儲存自己的session資料到cookie中n 反向代理hash一致性：u 做，保證一個使用者的請求落在一臺web-servern 後端統一儲存：web-server重啟和擴容，session也不會丟失l 我們最終選擇使用“後端統一儲存這種方式”SpringSession是基於“後端統一儲存”這種方式來管理session的； 只需配置一個Filter，SpringSession在Filter中使用裝飾者模式和介面卡模式包裝原生request。SpringSession可以選擇使用JDBC、Redis、Hazelcast、MongoDB等方式儲存sessionSpringSession也可以定製請求頭中帶sessionid或者cookie中帶sessionid我們選擇使用Redis儲存session 為什麼要使用Spring-session1、傳統方式session問題在傳統單機web應用中，一般使用tomcat/jetty等web容器時，使用者的session都是由容器管理。瀏覽器使用cookie中記錄sessionid，每次傳送請求的時候會帶上這個sessionid，web容器根據sessionid找到當時在服務儲存資訊時使用的那個Map，以此判斷使用者是否存在會話session。注意：最大的問題是，session儲存在web容器中，被單臺伺服器容器管理。在分散式情況下，這會導致什麼？當然，如果我們一直玩單機版的應用，不用關心這個問題，但是隨著業務逐漸增大，分散式應用和叢集是趨勢。

解決session不一致有很多方案，但多配置複雜或者有明顯的缺點。有了SpringSession，所有的session由SpringSession建立維護，無需我們修改任何程式碼，就能在叢集環境下使用原生的session方式程式設計，無侵入、簡單配置和Spring應用無縫整合、對接各種session儲存方案；

1. token替代session

2. NFS檔案系統儲存session

3. Redis儲存session

可以參考以下四種方式，具體採用那種根據實際專案情況做一個權衡 :

1.Session sticky(粘性):

思路就是某一個使用者第一次登陸時session儲存到哪個地方，第二次訪問時還去哪個伺服器找。

2.Session Relication(複製):

為每臺應用伺服器都儲存一份session資料，適用於機器比較少的情況

3.Session 共享:

將session資料集中儲存，所有的應用伺服器都來訪問這個session共享伺服器

4.cookie Base:

session資料存放在cookie中，然後在應用伺服器從cookies中生成對應的session資料，但是會有安全性的問題

session的作用

如果大家做過web應用開發的話，應該對session比較熟悉；伺服器會為每個使用者建立一個會話，儲存使用者的相關資訊，以便在後面的請求中，可以夠定位到同一個上下文。

例如使用者在登入之後，再進行頁面跳轉的時候，儲存在session中的資訊會一直保持，如果使用者還沒有session，那麼伺服器會建立一個session物件，直到會話過期或主動放棄後（退出），伺服器才會把session終止掉。

分散式架構中的session問題

在N年前，那個都是單個伺服器的年代，session直接儲存在伺服器中，是一點問題沒有的，而且實現起來很容易。

但是隨著分散式架構的流行，單個伺服器已經不能滿足系統的需要了，通常都會把系統部署在多臺伺服器上，透過負載均衡把請求分發到其中的一臺伺服器上，這樣很可能同一個使用者的請求被分發到不同的伺服器上，因為session是儲存在伺服器上的，那麼很有可能第一次請求訪問的A伺服器，建立了session，但是第二次訪問到了B伺服器，這時就會出現取不到session的情況。

於是，分散式架構中，session共享就成了一個很大的問題。

解決方案不要有session：大家可能覺得我說了句廢話，但是確實在某些場景下，是可以沒有session的，其實在很多介面類系統當中，都提倡【API無狀態服務】；也就是每一次的介面訪問，都不依賴於session、不依賴於前一次的介面訪問；存入cookie中：將session儲存到cookie中，但是缺點也很明顯，例如每次請求都得帶著session，資料儲存在客戶端本地，是有風險的；session同步：對個伺服器之間同步session，這樣可以保證每個伺服器上都有全部的session資訊，不過當伺服器數量比較多的時候，同步是會有延遲甚至同步失敗；使用Nginx（或其他複雜均衡軟硬體）中的ip繫結策略，同一個ip只能在指定的同一個機器訪問，但是這樣做風險也比較大，而且也是去了負載均衡的意義；我們現在的系統會把session放到Redis中儲存，雖然架構上變得複雜，並且需要多訪問一次Redis，但是這種方案帶來的好處也是很大的：實現session共享，可以水平擴充套件（增加Redis伺服器），伺服器重啟session不丟失（不過也要注意session在Redis中的重新整理/失效機制），不僅可以跨伺服器session共享，甚至可以跨平臺（例如網頁端和APP端）。