一口氣說出 4 種分布式一致性 Session 實現方式,面試杠杠的~

前言

公司有一個 Web 管理系統,使用 Tomcat 進行部署。由于是后臺管理系統,所有的網頁都需要登錄授權之后才能進行相應的操作。

起初這個系統的用的人也不多,為了節省資源,這個系統僅僅只是單機部署。后來隨著用的人越來越多,單機已經有點扛不住了,于是我決定再部署了一臺機器。

這時后端系統有兩臺服務,于是我們使用 Nginx 作為反向代理,整體架構圖如下:

這個架構圖想必大家應該比較熟悉,現在主流的 Web 系統應該都是這么部署。

經過一些調試之后,在一個夜深人靜的晚上,將這套系統部署到了生產。本以為沒有什么事的,很穩的交給測試小姐姐開始測試。

這一測,出了大問題!測試小姐姐反饋,登錄過后,沒過一會又需要登錄,操作好幾次都是這樣。

檢查了一下,系統應用,配置什么也沒問題,那到底哪里出了問題?

這個時候組長剛準備下班,看到我們這里有問題,于是過來了看了一下。簡單了解的一下基本情況,很快就找到了問題的原因,然后在 Nginx 端修改了下配置,重啟解決了問題。

先點后贊,養成習慣~關注公號『程序通事』,快來呀!!

分布式一致性 Session

解決完問題,組長坐下解釋了問題原因:分布式一致性 Session

原先我們登錄之后將會把用戶登錄信息放在 Session 中,用戶每次操作首先先校驗 Session 是否存在用戶信息,如果不存在將會強制讓用戶先去登錄。

原先架構的中我們只有一臺應用系統,所有操作都在一臺 Tomcat 上,這當然沒有什么問題。

但是現在我們部署了兩臺系統,由于 Nginx 使用默認負載均衡策略(輪詢),請求將會按照時間順序逐一分發到后端應用上。

也就是說剛開始我們在 Tomcat1 登錄之后,用戶信息放在 Tomcat1 的 Session 里。過了一會,請求又被 Nginx 分發到了 Tomcat2 上,這時 Tomcat2 上 Session 里還沒有用戶信息,于是又要登錄。

另外由于我們系統采用單點登錄的方式,Tomcat2 登錄之后會將 Tomcat1 登錄信息失效,于是乎等到 Nginx 再把流量分發到 Tomcat1 時,Session 中用戶登錄信息已經失效,又要重新登錄。

知道了問題,當然想知道解決辦法了,于是組長教了下分布式一致性 Session 四種解決辦法,小黑哥給大家整理了一下:

下面小黑哥將會以跟組長對話的形式,講解分布式一致性 Session 解決辦法。

Session 復制

組長:

如果此時 Tomcat1 Session 存在用戶信息,而 Tomcat2 上沒有存在。

這時如果我們將 Tomcat1 的 Session 復制到 Tomcat2 上,后面 Nginx 將請求轉發到 Tomcat2 上,由于 Tomcat2 存在 Session ,這時就不需要再重新登錄了。

架構圖如下:

一致性 Session-Session 復制

Tomcat 的 Session 復制的配置,網上有比較多的例子,這里小黑就不再貼了,感興趣的同學可以自行搜索一下。

小黑:

對的,這種方式挺好啊。Tomcat 就支持這種方式,我們只需要修改 Tomcat 配置就好,我們應用代碼都不用修改了。

組長:

說的對,但是這種方式還是有很多缺點。

第一,Session 復制傳輸需要占用內網帶寬。

第二,我們的例子就只有兩臺機器,這個復制性能還可以。但是假設我們有 N 臺機器,那么每次復制都要復制給 N-1 臺機器,如果機器很多,可能會形成網絡風暴,復制性能也會呈指數級下降。

第三, Tomcat 需要保存所有的 Session 數據,這個方案的 Session 存儲在內存中,容易受到機器的總內存的限制。我們沒辦法通過加機器的方式水平擴展,我們能做的方式就是加大機器內存。但是機器內存越大,價格真的很貴!!!

所以不推薦使用這種方案。

Session 前端存儲

小黑:

恩,這個方案確實有點不靠譜~

哎,有了!我們的 Session 里面其實就是存了用戶的信息,那我現在不存 Tomcat Session 里,我把信息拿出來,存到瀏覽器的 Cookie 中。

這樣,每個用戶瀏覽器存儲自己的 Cookie 信息,服務端就不需要存儲,這就解決了 Session 復制方案的缺陷了。

接下來用戶每次請求都把這個 Cookie 給我發過來,我判斷 Cookie 里面用戶信息不就好了。

架構圖如下:

一致性 Session-Session 前端存儲

組長,欣賞看了一下我:

對,你這個方案確實可行。

不過么,如果用這種方案,首先你要想好加密方案。

用戶信息可是我們的敏感數據,不能讓別人輕易的竊取或者篡改數據了。

除了這個,這個方案每次請求都要攜帶 Cookie 傳輸,這會占用外網的帶寬,如果 Cookie 過大,會增大網絡的開銷。

另外,我們存儲的數據大小,容易受到 Cookie 限制。

所以這種還是不怎么常用,不過也是一種思路。

我比較推薦下面兩種方案。

Session 粘滯(Sticky Sessions)

組長:

剛才應該看到了,我只是對 Nginx 的配置做了一些修改,然后這個問題就解決了吧。

其實這是因為我修改 Nginx 默認的負載均衡策略,使用 IP Hash 的方式。

Nginx 會使用請求者的 IP 來做 Hash,然后分發到一臺機器上,這樣可以保證同一 IP 的請求都落在同一臺 Tomcat 上。

架構圖如下:

Session 粘滯-IP Hash

上面這種方式我們使用 Nginx 四層負載均衡方式,其實 Nginx 還可以做到七層負載均衡方式,也就是使用 Http 協議中的一些業務屬性來做 Hash,常見的有 userId,loginId等等。

架構圖如下:

一致性 Session-Session 粘滯-七層

小黑:

這種方案看起來挺簡單的,我們只需要修改 Nginx 配置就好了,應用端配置無需改動。

只要請求來源 IP 足夠的隨機,那么 IP HASH 之后兩臺應用上的流量將會足夠隨機。

另外后面如果兩臺機器扛不住,我們還可以水平擴展,再加機器,只要修改 Nginx 配置即可。

組長:

你說的這幾點都很正確!

不過你有沒有想過,像我們公司這種情況,所有人的出口的 IP 都是一個。那么我們公司的所有請求只會到一臺機器上,那我們這種情況等于又變成單點了。

另外如果 Tomcat 重啟,Session 由于是放置在內存內存中,這一部分的 Session 將會丟失,這就導致這部分用戶將會重新登錄。

最后,如果我們臨時再加機器,修改完 Nginx 配置,重新啟動之后,Nginx 將會重新計算 Hash 分發請求。

這種情況就會導致有一部分用戶重新路由到一臺新機器上,由于沒有 Session,又需要重新登錄了。

不過么,Tomcat 重啟或者新加機器次數不會很多,所以這個問題也不大,用戶體驗稍差點。

今天的我們這個問題解決方案就先使用這個。

不過后面我們還是改成下面這種方式。

后端集中存儲

組長:

上面幾種的方式我們都是把 Session 存儲在應用內存上,應用機器只要重啟,Session 就會丟失。

為了這個解決這個問題,我們將 Session 單獨存起來,保存到 Redis 或者 MySQL 中。

不過由于 Session 需要過期失效的特性,不需要持久化保存,所以這里我建議使用 Redis 來保存。

這樣架構就變成下方這樣的:

一致性 Session-Session 后端存儲

我們使用這種方案,上沒有 Session 丟失的風險,當然前提是 Redis 不能宕機。

另外后期如果應用可以直接水平擴展。

如果后面應用的請求量很大,一臺 Redis 扛不住了,那我們可以其實可以做集群擴展,根據緩存 Key 做路由。

小黑:

對對,這種方式好~

組長:

你不要高興的太早,我們使用這個方案需要付出一定的代價的。

首先我們每次請求都需要調用一次 Redis ,這就增加一次網絡的開銷。

另外,引入 Redis,我們需要對相應的代碼做出修改,這樣復雜度就變高。

所以說,這個方案有利也有弊,當然對于我們的場景來說,利大于弊。

小黑:

恩,好像是這樣的。

組長:

好了,這么晚了,問題解決了,我們去擼個串,我請客!

小黑:

老大,??!

組長拍了拍小黑的腦袋:

我這一頓不是白吃哦,下個星期你把現在方式修改一下,修改成 Session 集中存儲的方式。

給你一個小提示,可以使用 spring-session

小黑:

好吧,吃人嘴短,下周我研究下。

總結

最后總結一下,當我們后端 Web 應用擴展到多臺后,我們就會碰到分布式一致性 Session 的問題,主流解決方案有四種:

  • Session 復制:利用 Tomcat 等 Web 容器同步復制
  • Session 前端存儲:利用用戶瀏覽器中 Cookie 保存 Session 信息
  • Session 粘滯方案:利用 Nginx 可以做四層 Hash 或七層 Hash 的特性,保證用戶的請求都落在同一臺機器上
  • Session 后端集中存儲方案:利用 Redis 集中存儲 Session,Web 應用重啟或擴容,Session 也無需丟失。

上面四種方案,優先推薦第四種。

當然第四種方案需要一定的開發工作量,前期還沒改造的過程可以選擇 第三種方案中間過渡。

好了,后面就要使用 Session 后端存儲方案改造這個工程了,后面小黑哥再跟大家分享一下 spring-session

幫助

  1. 架構師之路-session一致性架構設計實踐

歡迎關注我的公眾號:程序通事,獲得日常干貨推送。如果您對我的專題內容感興趣,也可以關注我的博客:studyidea.cn

posted @ 2020-07-17 08:41  樓下小黑哥  閱讀(...)  評論(...編輯  收藏
最新chease0ldman老人