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

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