session的概念什麼是session？伺服器為每個使用者建立一個會話，儲存使用者的相關資訊，以便多次請求能夠定位到同一個上下文。這樣，當用戶在應用程式的 Web 頁之間跳轉時，儲存在 Session 物件中的變數將不會丟失，而是在整個使用者會話中一直存在下去。當用戶請求來自應用程式的 Web 頁時，如果該使用者還沒有會話，則 Web 伺服器將自動建立一個 Session 物件。當會話過期或被放棄後，伺服器將終止該會話。Web開發中，web-server可以自動為同一個瀏覽器的訪問使用者自動建立session，提供資料儲存功能。最常見的，會把使用者的登入資訊、使用者資訊儲存在session中，以保持登入狀態。什麼是session一致性問題？只要使用者不重啟瀏覽器，每次http短連線請求，理論上服務端都能定位到session，保持會話。分散式session單伺服器web應用中，session資訊只需存在該伺服器中，這是我們前幾年最常接觸的方式，但是近幾年隨著分散式系統的流行，單系統已經不能滿足日益增長的百萬級使用者的需求，叢集方式部署伺服器已在很多公司運用起來，當高併發量的請求到達服務端的時候透過負載均衡的方式分發到叢集中的某個伺服器，這樣就有可能導致同一個使用者的多次請求被分發到叢集的不同伺服器上，就會出現取不到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反向代理層使用使用者ip來做hash，以保證同一個ip的請求落在同一個web-server上 方案二：七層代理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失效，一般問題不大。對於四層hash還是七層hash，個人推薦前者：讓專業的軟體做專業的事情，反向代理就負責轉發，儘量不要引入應用層業務屬性，除非不得不這麼做（例如，有時候多機房多活需要按照業務屬性路由到不同機房的web-server）。 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去做這樣的事情吧。

我們知道web應用是基於http協議的，而http協議從設計之初就是上下文無關的，這就是說http的每一個請求都是完全獨立的。這個特點在早期的靜態網站中是沒有什麼問題的，每個頁面都是獨立的。

但隨著web應用的不斷髮展，現在的web應用可以處理複雜的業務，而上下文無關的http協議是沒辦法支援複雜業務的，例如使用者登入後，伺服器需要知道每一次請求是來自客戶端的哪一個使用者，根據不同的使用者返回結果。所以現在的web伺服器建立了session，利用http協議中的cookie儲存和傳遞session id將瀏覽器多個請求關聯起來，這樣在web服務端就可以透過session維護前端請求的複雜的業務關係。

而隨著web應用規模的不斷擴大，單臺web伺服器已經不能滿足效能要求，因此複雜的web應用伺服器多為多臺伺服器叢集處理，但這種叢集就可能導致在單臺伺服器上維護業務上下文關係的session在多臺伺服器上失效，這就產生了session一致性的需求。

那麼如何解決呢？最簡單的就是限定單個session的業務只能由建立session的伺服器處理，風險是單臺伺服器失效導致該伺服器上相關的session的業務失效；其次就是session複製，就是當請求到達其它伺服器時，伺服器可以從擁有該session的伺服器上覆制session的資訊到當前伺服器，完成請求業務，缺點是session複製（同步）處理複雜；最後也是目前最流行的就是session共享方案，即session在所有服務之間共享（透過資料庫或快取服務共享），從而保證session的一致性，如目前主流的應用是將session建立在redis快取中供伺服器訪問。