session一致性的解決方案

• 2019 年 10 月 3 日
• 筆記

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

什麼是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的負載均勻

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