Session問題原因分析

從根本上來說是因為Http協議是無狀態的協議。客戶端和服務端在某次會話中產 生的資料不會被保留下來，所以第二次請求服務端無法認識到你曾經來過， Http為什麼要設計為無狀態 協議?早期都是靜態⻚面無所謂有無狀態，後來有動態的內容更豐富，就需要有狀態，出現了兩種用於 保持Http狀態的技術，那就是Cookie和Session。

場景：nginx預設輪詢策略

Session一致性的方案

Nginx的 IP_Hash 策略(可以使用)

同一個客戶端IP的請求都會被路由到同一個目標伺服器，也叫做會話粘滯

優點:

配置簡單，不入侵應用，不需要額外修改程式碼

缺點:
伺服器重啟Session丟失

存在單點負載高的⻛險 單點故障問題

Session複製(不推薦)

也即，多個tomcat之間通過修改配置檔案，達到Session之間的複製

優點:

不入侵應用

便於伺服器水平擴充套件 能適應各種負載均衡策略 伺服器重啟或者宕機不會造成Session丟失

缺點:

效能低

記憶體消耗

不能儲存太多資料，否則資料越多越影響效能

延遲性

Session共享，Session集中儲存(推薦)

Session的本質就是快取，那Session資料為什麼不交給專業的快取中介軟體呢?比如Redis

優點:

能適應各種負載均衡策略 伺服器重啟或者宕機不會造成Session丟失擴充套件能力強

適合大叢集數量使用

缺點:

對應用有入侵，引入了和Redis的互動程式碼

redis解決Session問題例項

引入jar

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
<dependency>
  <groupId>org.springframework.session</groupId>
  <artifactId>spring-session-data-redis</artifactId>
</dependency>
 

配置redis

spring.redis.database=0
spring.redis.host=127.0.0.1
spring.redis.port=6379

添加註解

redis解決Session問題原理