【入門】分散式Session一致性入門簡介

阿飛雲發表於2019-04-15
分散式Session

Session簡介

是什麼？

  1. Session在網路中表示“會話控制”，用於儲存特定使用者所需的屬性和其他的配置資訊；
  2. Session表示一個特定的時間間隔，可以指使用者從登陸系統到登出退出系統之家的時間。

為什麼出現？

因為http 是一種無狀態協議，如果沒有Session的話，伺服器無法識別請求是否來自同一個使用者！ 在一些業務場景中需要知道前面的操作和後臺的操作是不是同一個使用者的行為，即業務之間是有關聯性的。

怎麼用？

使用Session結合瀏覽器Cookie，將伺服器Session儲存到瀏覽器cookie中，這樣可以保持http會話狀態。 Session伺服器建立，如Tomcat，瀏覽器發起請求到Tomcat伺服器，然後Tomcat伺服器生成SessionId儲存在記憶體中，並將SessionId返回給瀏覽器，瀏覽器通過Cookie儲存SessionId資訊，使用者每次通過瀏覽器訪問伺服器都會帶上SessionId資訊，這樣就可以判斷每次的請求是不是同一個使用者，解決http協議無狀態問題。

什麼是Session一致性問題

單機版的系統，比如一個Tomcat部署，是不存在Session一直性的問題，因為Session儲存在一個Tomcat容器中。

Session一致性問題是由架構演進或者業務的演進中發生，從單機演進到叢集或者分散式的架構

使用者---> 瀏覽器 ----> Nginx（輪詢） -----> n（多）臺Web伺服器

比如Nginx使用輪詢方式，使用者第一次請求，請求被分配到到了 A web伺服器，使用者在A web伺服器上進行登入，並儲存登入資訊（Session資訊），並將Session資訊響應給瀏覽器。當使用者第二次在請求的時候 通過輪詢會定位到B web伺服器，此時B web伺服器上沒有 使用者的登入資訊（Session資訊），則會提示使用者進行登入，此時使用者就會很萌B！

上面的描述就是一種產生Session不一致的例子。

Session一致性問題的解決方案

方案1

使用Nginx的ip_hash策略來做負載均衡

ip_hash策略的原理：根據Ip做hash計算，同一個Ip的請求始終會定位到一臺web伺服器上。

使用者---> 瀏覽器 ----> Nginx（ip_hash） -----> n（多）臺Web伺服器

同一個使用者（Ip）---> 瀏覽器 ----> Nginx（ip_hash） -----> A Web伺服器

此時假如使用者IP為 192.168.1.110 被hash到 A web伺服器，那麼使用者的請求就一直會訪問A web伺服器了。

優點：

  1. 配置簡單，只需要在Nginx中配置好ip_hash 策略
  2. 對應用無侵入性，應用不需要改任何
  3. ip_hash策略會很均勻的講使用者請求的ip分配到web伺服器上，並且可以動態的水平擴充套件web伺服器（只需在配置中加上伺服器即可）

缺點:

假如有一臺Tomcat 當機或者重啟，那麼這一臺伺服器上的使用者的Session資訊丟失，導致單點故障。

方案2

使用伺服器Session複製

伺服器Session複製原理：Web伺服器器建立Session後，會通過組播方式把Session傳送到組播地址中的其他伺服器上

使用者---> 瀏覽器 ----> Nginx（輪詢） -----> n（多）臺Web伺服器 (Session複製)

Tomcat的server.xml配置

<Cluster className="org.apacche.catalina.ha.tcp.simpleTcpCluster"/>

//tomcat session會話複製

複製程式碼

tomcat session會話複製

優點：

  1. 對應用的侵入性有一點（應用中web.xml需要加上 標識是分散式的。對應該有侵入性。），但是還是比較小。
  2. Nginx可以配置輪詢和ip_hash，能夠適應各種負載均衡策略
  3. 一個Tomcat當機不會影響Session丟失問題，解決了ip_hash 的問題

缺點：

  1. Session同步會有延遲，會影頻寬
  2. 受限於記憶體資源，在大使用者量，高併發，高流量場景，會佔用大量記憶體，不適合！
  3. 增加伺服器不靈活，不易於擴充套件
  4. 伺服器重啟後會有問題

方案3

使用Session集中統一管理

使用Session集中統一管理原理： Session不在由web伺服器管理，而是統一放到一個地方集中式管理，讀取和寫入Session都依賴第三方軟體。例如Redis、MongoDB、mysql等

使用者---> 瀏覽器 ----> Nginx（輪詢） -----> n（多）臺Web伺服器 ----> redis(叢集)

優點：

  1. 擴充套件能力強
  2. 伺服器當機後Session不會丟失

缺點：

  1. 對應用有侵入性，要增加一些配置檔案
  2. 需要依賴第三方的庫
  3. 需要搭建Redis的服務

應用場景：網際網路專案，大型分散式、大併發場景下，首先方案！

本系列教程

【入門】分散式Session一致性入門簡介

【第一篇】Spring-Session實現Session共享入門教程

【第二篇】Spring-Session實現Session共享Redis叢集方式配置教程

【第三篇】Spring-Session實現Session共享實現原理以及原始碼解析

牆裂 推薦：session一致性架構設計實踐

謝謝你的閱讀，如果您覺得這篇博文對你有幫助，請點贊或者喜歡，讓更多的人看到！祝你每天開心愉快！


不管做什麼，只要堅持下去就會看到不一樣！在路上，不卑不亢!

願你我在人生的路上能都變成最好的自己，能夠成為一個獨擋一面的人

【入門】分散式Session一致性入門簡介

© 每天都在變得更好的阿飛雲

相關文章