session一致性的解決方案

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

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

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