7.登入系統-單點登入問題-分散式session一致性(即session如何共享)的問題
如上圖,假設使用者包含登入資訊的session都記錄在第一臺web-server上,反向代理如果將請求路由到另一臺web-server上,可能就找不到相關資訊,而導致使用者需要重新登入。
Session一致性解決方案1.session複製(同步)思路:多個web-server之間相互同步session,這樣每個web-server之間都包含全部的session
優點:web-server支援的功能,應用程式不需要修改程式碼
不足:
session的同步需要資料傳輸,佔內網頻寬,有時延
所有web-server都包含所有session資料,資料量受記憶體限制,無法水平擴充套件
有更多web-server時要歇菜
2.客戶端儲存法
思路:服務端儲存所有使用者的session,記憶體佔用較大,可以將session儲存到瀏覽器cookie中,每個端只要儲存一個使用者的資料了
優點:服務端不需要儲存
缺點:
每次http請求都攜帶session,佔外網頻寬
資料儲存在端上,並在網路傳輸,存在洩漏、篡改、竊取等安全隱患
session儲存的資料大小受cookie限制
“端儲存”的方案雖然不常用,但確實是一種思路。
3.反向代理hash一致性
思路:web-server為了保證高可用,有多臺冗餘,反向代理層能不能做一些事情,讓同一個使用者的請求保證落在一臺web-server上呢?
方案一:四層代理hash
反向代理層使用使用者方案二:七層代理hash
反向代理使用http協議中的某些業務屬性來做hash,例如sid,city_id,user_id等,能夠更加靈活的實施hash策略,以保證同一個瀏覽器使用者的請求落在同一個web-server上
優點:
只需要改nginx配置,不需要修改應用程式碼
負載均衡,只要hash屬性是均勻的,多臺web-server的負載是均衡的
可以支援web-server水平擴充套件(session同步法是不行的,受記憶體限制)
不足:
如果web-server重啟,一部分session會丟失,產生業務影響,例如部分使用者重新登入
如果web-server水平擴充套件,rehash後session重新分佈,也會有一部分使用者路由不到正確的session
session一般是有有效期的,所有不足中的兩點,可以認為等同於部分session失效,一般問題不大。
4.後端統一集中儲存思路:將session儲存在web-server後端的儲存層,資料庫或者快取
優點:沒有安全隱患可以水平擴充套件,資料庫/快取水平切分即可web-server重啟或者擴容都不會有session丟失不足:增加了一次網路呼叫,並且需要修改應用程式碼對於db儲存還是cache,個人推薦後者:session讀取的頻率會很高,資料庫壓力會比較大。如果有session高可用需求,cache可以做高可用,但大部分情況下session可以丟失,一般也不需要考慮高可用。總結保證session一致性的架構設計常見方法:session同步法:多臺web-server相互同步資料客戶端儲存法:一個使用者只儲存自己的資料反向代理hash一致性:四層hash和七層hash都可以做,保證一個使用者的請求落在一臺web-server上後端統一儲存:web-server重啟和擴容,session也不會丟失對於方案3和方案4,個人建議推薦後者:web層、service層無狀態是大規模分散式系統設計原則之一,session屬於狀態,不宜放在web層讓專業的軟體做專業的事情,web-server存session?還是讓cache去做這樣的事情吧。