更多內容，歡迎關注微信公眾號：全菜工程師小輝。公眾號回覆關鍵詞，領取免費學習資料。

什麼是session？

伺服器為每個使用者建立一個會話，儲存使用者的相關資訊，以便多次請求能夠定位到同一個上下文，這個相關資訊就是session。這樣，當用戶在應用程式的Web頁之間跳轉時，儲存在session物件中的變數將不會丟失，而是在整個使用者會話中一直存在下去。

session是對http無狀態協議的補充，達到狀態保持的目的

什麼是session一致性問題？

假設使用者包含登入資訊的session都記錄在第一臺server上，反向代理如果將請求路由到另一臺server上，可能就找不到相關資訊，而導致使用者需要重新登入。

解決方法

1. 客戶端儲存cookie

• 優點：

1. 服務端不需要儲存

• 缺點：

1. 每次http請求都攜帶session，佔網絡頻寬
2. 資料儲存在客戶端上，並在網路傳輸，存在洩漏、篡改等安全隱患
3. session儲存的資料大小受cookie限制

由於技術不斷演進，客戶端儲存cookie出現了資訊全量cookie，cookie儲存sessionId和JWT三種方式，他們優缺點各異，可以點選筆者的另一篇部落格檢視相關介紹

快速瞭解會話管理三劍客cookie、session和JWT

2. session複製方法

• 思路：
  多個server之間相互同步session，這樣每個server之間都包含全部的session
• 優點：

1. 只需要設定配置，應用程式不需要修改程式碼

• 不足：

1. session的同步需要資料傳輸，佔內網頻寬，有延時
2. 所有server都包含所有session資料，資料量受最小記憶體的sever限制，水平拓展能力差

3. session中心儲存

• 思路：
  將session儲存在server後端的集中式快取

• 優點：

1. 沒有安全隱患
2. 可以水平擴充套件，支援快取叢集或橫向拓展

• 不足：

1. 增加了一次網路呼叫
2. 需要修改應用程式碼

4. session會話粘連

session會話粘連：英文原詞為"Sticky Sessions"

• 思路：
  反向代理層讓同一個使用者的請求保證落在一臺server上呢？

• 方法一：四層代理hash。反向代理層使用使用者ip來做hash，以保證同一個ip的請求落在同一個server上（更推薦，保證傳輸層不引入業務層的邏輯）

• 方法二：七層代理hash。反向代理使用http協議中的某些業務屬性來做hash，例如sid，city_id，user_id等，能夠更加靈活的實施hash策略，以保證同一個瀏覽器使用者的請求落在同一個server上

• 優點：

1. 只需要改nginx配置，不需要修改應用程式碼
2. 可以支援server水平擴充套件

• 不足：

1. server水平擴充套件，rehash後session重新分佈，會有一部分使用者路由不到正確的session
2. 即使hash雜湊均勻，也不能保證server的負載均勻

更多內容，歡迎關注微信公眾號：全菜工程師小輝。公眾號回覆關鍵詞，領取免費學習資料。

相關推薦