分佈式Session共享的4類技術方案，與優劣勢比較

Session概念集合

服務器爲每一個用戶建立一個會話，存儲用戶的相關信息，以便屢次請求可以定位到同一個上下文。這樣，當用戶在應用程序的 Web 頁之間跳轉時，存儲在 Session 對象中的變量將不會丟失，而是在整個用戶會話中一直存在下去。

當用戶請求來自應用程序的 Web 頁時，若是該用戶尚未會話，則 Web 服務器將自動建立一個 Session 對象。當會話過時或被放棄後，服務器將終止該會話。

Web開發中，web-server能夠自動爲同一個瀏覽器的訪問用戶自動建立session，提供數據存儲功能。最多見的，會把用戶的登陸信息、用戶信息存儲在session中，以保持登陸狀態。

什麼是session一致性問題？

只要用戶不重啓瀏覽器，每次http短鏈接請求，理論上服務端都能定位到session，保持會話。

分佈式session

單服務器web應用中，session信息只需存在該服務器中，這是咱們前幾年最常接觸的方式，可是近幾年隨着分佈式系統的流行，單系統已經不能知足日益增加的百萬級用戶的需求，集羣方式部署服務器已在不少公司運用起來，當高併發量的請求到達服務端的時候經過負載均衡的方式分發到集羣中的某個服務器，這樣就有可能致使同一個用戶的屢次請求被分發到集羣的不一樣服務器上，就會出現取不到session數據的狀況，因而session的共享就成了一個問題。

這個時候就須要解決Session一致性。

Session一致性解決方案

一、session複製

session複製是早期的企業級的使用比較多的一種服務器集羣session管理機制。

應用服務器開啓web容器的session複製功能，在集羣中的幾臺服務器之間同步session對象，使得每臺服務器上都保存全部的session信息，這樣任何一臺宕機都不會致使session的數據丟失，服務器使用session時，直接從本地獲取。

簡介： 將一臺機器上的Session數據廣播複製到集羣中其他機器上

session複製使用場景：機器較少，網絡流量較小

優勢： 實現簡單、配置較少、當網絡中有機器Down掉時不影響用戶訪問

缺點：廣播式複製到其他機器有必定廷時，帶來必定網絡開銷。

這種方式在應用集羣達到數千臺的時候，就會出現瓶頸，每臺都須要備份session，出現內存不夠用的狀況。

二、session綁定

利用hash算法，好比nginx的ip_hash,使得同一個Ip的請求分發到同一臺服務器上。

session綁定使用場景：機器數適中、對穩定性要求不是很是苛刻

優勢：實現簡單、配置方便、沒有額外網絡開銷

缺點：網絡中有機器Down掉時、用戶Session會丟失、容易形成單點故障。

這種方式不符合對系統的高可用要求，由於一旦某臺服務器宕機，那麼該機器上的session也就不復存在了，用戶請求切換到其餘機器後麼有session，沒法完成業務處理。

三、利用cookie記錄session

session記錄在客戶端，每次請求服務器的時候，將session放在請求中發送給服務器，服務器處理完請求後再將修改後的session響應給客戶端，這裏的客戶端就是cookie。

缺點

好比受cookie大小的限制，能記錄的信息有限；

每次請求響應都須要傳遞cookie，影響性能，若是用戶關閉cookie，訪問就不正常。

優勢：

cookie的簡單易用，可用性高，支持應用服務器的線性伸縮，而大部分要記錄的session信息比較小，所以事實上，許多網站或多或少的在使用cookie記錄session。

四、session服務器

session服務器能夠解決上面的全部的問題，利用獨立部署的session服務器（集羣）統一管理session，服務器每次讀寫session時，都訪問session服務器。

這種解決方案事實上是應用服務器的狀態分離，分爲無狀態的應用服務器和有狀態的session服務器，而後針對這兩種服務器的不一樣特性分別設計架構。

對於有狀態的session服務器，一種比較簡單的方法是利用分佈式緩存（redis、memcached), 或者存儲在數據庫(如MySQL)等。在這些產品的基礎上進行包裝，使其符合session的存儲和訪問要求。

若是業務場景對session管理有比較高的要求，好比利用session服務基層單點登陸（sso),用戶服務器等功能，須要開發專門的session服務管理平臺。

session服務器使用場景：集羣中機器數多、網絡環境複雜。

優勢：可靠性好

缺點：實現複雜、穩定性依賴於緩存的穩定性、Session信息放入緩存時要有合理的策略寫入。