分散式架構下的 Session 共享，也稱作分散式 Session 一致性；分散式架構下 Session 共享有哪些問題，又有哪些解決方案，讓我們一起看一下。

Session 的作用

如果大家做過 Web 應用開發的話，應該對 Session 比較熟悉；伺服器會為每個使用者建立一個會話，儲存使用者的相關資訊，以便在後面的請求中，可以夠定位到同一個上下文。

✔︎ 舉個例子

使用者在登入之後，再進行頁面跳轉的時候，儲存在 Session 中的資訊會被一直儲存；

如果使用者沒有 Session ，那麼伺服器會建立一個 Session 物件，直到會話過期或主動放棄後（退出），伺服器才會把 Session 終止掉。

分散式架構中 Session 的問題

✔︎ 單體架構

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

✘ 分散式架構

但是隨著分散式架構的流行，單個伺服器已經不能滿足系統的需要了，通常都會把系統部署在多臺伺服器上，通過負載均衡把請求分發到其中的一臺伺服器上；

那麼很有可能第一次請求訪問的 A 伺服器，建立了 Session ，但是第二次訪問到了 B 伺服器，這時就會出現取不到 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 端）。

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