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去做這樣的事情吧。

彙總於網路，供自己學習使用。