分佈式架構下，Session 共享有什麼方案？

編程改變世界

分佈式架構下的 Session 共享，也稱做分佈式 Session 一致性；分佈式架構下 Session 共享有哪些問題，又有哪些解決方案，讓咱們一塊兒看一下。

Session 的做用

若是你們作過 Web 應用開發的話，應該對 Session 比較熟悉；服務器會爲每一個用戶建立一個會話，存儲用戶的相關信息，以便在後面的請求中，能夠夠定位到同一個上下文。

✔︎ 舉個例子

用戶在登陸以後，再進行頁面跳轉的時候，存儲在 Session 中的信息會被一直保存；

若是用戶沒有 Session ，那麼服務器會建立一個 Session 對象，直到會話過時或主動放棄後（退出），服務器纔會把 Session 終止掉。

Session 的做用

分佈式架構中 Session 的問題

✔︎ 單體架構

在單體服務器的年代，Session 直接保存在服務器中，是沒有問題的，並且實現起來很容易。

✘ 分佈式架構

可是隨着分佈式架構的流行，單個服務器已經不能知足系統的須要了，一般都會把系統部署在多臺服務器上，經過負載均衡把請求分發到其中的一臺服務器上；

那麼頗有可能第一次請求訪問的 A 服務器，建立了 Session ，可是第二次訪問到了 B 服務器，這時就會出現取不到 Session 的狀況；

因而，分佈式架構中，Session 共享就成了一個很大的問題。

分佈式架構中 Session 的問題

解決方案

1. 不要有 Session

你們可能以爲我說了句廢話，可是確實在某些場景下，是能夠沒有 Session 的，其實在不少接口類系統當中，都提倡【 無狀態服務 】；也就是每一次的接口訪問，都不依賴於 Session ，不依賴於前一次的接口訪問；

2. 存入 Cookie 中

能夠將 Session 存儲到 Cookie 中，可是缺點也很明顯，例如每次請求都得帶着 Session ，數據存儲在客戶端本地，是有風險的；

3. Session 同步

服務器之間進行 Session 同步，這樣能夠保證每一個服務器上都有所有的 Session 信息，不過當服務器數量比較多的時候，同步是會有延遲甚至同步失敗；

4. IP 綁定策略

使用 Nginx （或其餘複雜均衡軟硬件）中的 IP 綁定策略，同一個 IP 只能在指定的同一個機器訪問，可是這樣作失去了負載均衡的意義，當掛掉一臺服務器的時候，會影響一批用戶的使用，風險很大；

5. 使用 Redis 存儲

咱們如今的系統會把 Session 放到 Redis 中存儲，雖然架構上變得複雜，而且須要多訪問一次 Redis ，可是這種方案帶來的好處也是很大的：

• 實現了 Session 共享；
• 能夠水平擴展（增長 Redis 服務器）；
• 服務器重啓 Session 不丟失（不過也要注意 Session 在 Redis 中的刷新/失效機制）；
• 不只能夠跨服務器 Session 共享，甚至能夠跨平臺（例如網頁端和 APP 端）。

分佈式架構中 Session 共享解決方案

會點代碼的大叔 | 文【原創】

---

會點代碼的大叔