基於Session共享的方式解決單點登錄問題

本文主要講述集羣環境下解決Session共享的問題,從而實現集羣環境下的單點登錄。Session共享問題已經有很多解決方案,這裏主要講述常用四種方法。

Session Sticky

Session Sticky(粘性) 保證同一個會話的請求都在同一個Web服務器上處理,這樣就完全不需要考慮到會話問題了。比如負載均衡算法中哈希算法就是一個典型的Session Sticky實現手段。

這種實現方式存在問題:

1)如果一臺Web服務器宕機或者重啓,那麼這臺機器上保存的會話數據都會丟失,會造成用戶暫時無法訪問的問題,之前的授權操作需要再執行一次;

2)通過這種方式實現的Session保持,無法進行4層網絡轉發,只能在7層網絡上進行解析並轉發。

Session Replication

Session Replication(複製)通過相關技術實現Session複製,使集羣中的各個服務器保存所有節點的session數據。tomcat本身就可以實現session複製的功能,基於IP組播放方式。

這種實現方式的問題:

1)同步Session數據會造成網絡開銷,隨着集羣規模越大,同步Session帶來的帶寬影響也越大;

2)每個節點需要保存集羣中所有節點的Session數據,就需要比較大的內存來存儲。

Session統一存儲

集羣中的各個節點的Session數據,統一存儲到一個存儲設備中。客戶端訪問需要Session的時候,就不是從某個節點的內存中去獲得,而是從相應的第三方存儲中去獲取。對於這個方案來說,無論是哪個節點新增或者修改了Session數據,最終都會發生在這個集中存儲的地方。採用的Session存儲有redis、mysql。

這種實現方式的問題:

1)讀寫Session數據需要進行網絡操作,存在不穩定性和延遲性;

2)如果存儲Session的服務器出現故障,將大規模的影響到應用。

Cookie Based

Cookie Based方法簡單來說,就是不依賴容器本身的Session機制。而是服務端基於一定的算法,生成一個token給到客戶端,客戶端每次請求都會攜帶這個token。當服務端收到token 以後,先驗證token是否有效,然後對客戶端訪問進行授權。

比較典型的方式是JWT(JSON Web Tokens),它是一種簡潔的並且在兩個計算機之間安全傳遞信息的表述性聲明規範。JWT的聲明一般被用來在客戶端和服務端之間傳遞被認證的用戶身份信息,以便於從資源服務器獲取資源。比如用在用戶登錄上。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章