前言
公司有一個 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 ，這時就不需要再重新登入了。
架構圖如下：
Tomcat 的 Session 複製的配置，網上有比較多的例子，這裡小黑就不再貼了，感興趣的同學可以自行搜尋一下。
小黑：
對的，這種方式挺好啊。Tomcat 就支援這種方式，我們只需要修改 Tomcat 配置就好，我們應用程式碼都不用修改了。
組長：
說的對，但是這種方式還是有很多缺點。
第一，Session 複製傳輸需要佔用內網頻寬。
第二，我們的例子就只有兩臺機器，這個複製效能還可以。但是假設我們有 N 臺機器，那麼每次複製都要複製給 N-1 臺機器，如果機器很多，可能會形成網路風暴，複製效能也會呈指數級下降。
第三， Tomcat 需要儲存所有的 Session 資料，這個方案的 Session 儲存在記憶體中，容易受到機器的總記憶體的限制。我們沒辦法通過加機器的方式水平擴充套件，我們能做的方式就是加大機器記憶體。但是機器記憶體越大，價格真的很貴！！！
所以不推薦使用這種方案。
Session 前端儲存
小黑：
恩，這個方案確實有點不靠譜~
哎，有了！我們的 Session 裡面其實就是存了使用者的資訊，那我現在不存 Tomcat Session 裡，我把資訊拿出來，存到瀏覽器的 Cookie 中。
這樣，每個使用者瀏覽器儲存自己的 Cookie 資訊，服務端就不需要儲存，這就解決了 Session 複製方案的缺陷了。
接下來使用者每次請求都把這個 Cookie 給我發過來，我判斷 Cookie 裡面使用者資訊不就好了。
架構圖如下：
組長，欣賞看了一下我：
對，你這個方案確實可行。
不過麼，如果用這種方案，首先你要想好加密方案。
使用者資訊可是我們的敏感資料，不能讓別人輕易的竊取或者篡改資料了。
除了這個，這個方案每次請求都要攜帶 Cookie 傳輸，這會佔用外網的頻寬，如果 Cookie 過大，會增大網路的開銷。
另外，我們儲存的資料大小，容易受到 Cookie 限制。
所以這種還是不怎麼常用，不過也是一種思路。
我比較推薦下面兩種方案。
Session 粘滯（Sticky Sessions）
組長：
剛才應該看到了，我只是對 Nginx 的配置做了一些修改，然後這個問題就解決了吧。
其實這是因為我修改 Nginx 預設的負載均衡策略，使用 IP Hash 的方式。
Nginx 會使用請求者的 IP 來做 Hash，然後分發到一臺機器上，這樣可以保證同一 IP 的請求都落在同一臺 Tomcat 上。
架構圖如下：
上面這種方式我們使用 Nginx 四層負載均衡方式，其實 Nginx 還可以做到七層負載均衡方式，也就是使用 Http 協議中的一些業務屬性來做 Hash，常見的有 userId,loginId等等。
架構圖如下：
小黑：
這種方案看起來挺簡單的，我們只需要修改 Nginx 配置就好了，應用端配置無需改動。
只要請求來源 IP 足夠的隨機，那麼 IP HASH 之後兩臺應用上的流量將會足夠隨機。
另外後面如果兩臺機器扛不住，我們還可以水平擴充套件，再加機器，只要修改 Nginx 配置即可。
組長：
你說的這幾點都很正確！
不過你有沒有想過，像我們公司這種情況，所有人的出口的 IP 都是一個。那麼我們公司的所有請求只會到一臺機器上，那我們這種情況等於又變成單點了。
另外如果 Tomcat 重啟，Session 由於是放置在記憶體記憶體中，這一部分的 Session 將會丟失，這就導致這部分使用者將會重新登入。
最後，如果我們臨時再加機器，修改完 Nginx 配置，重新啟動之後，Nginx 將會重新計算 Hash 分發請求。
這種情況就會導致有一部分使用者重新路由到一臺新機器上，由於沒有 Session，又需要重新登入了。
不過麼，Tomcat 重啟或者新加機器次數不會很多，所以這個問題也不大，使用者體驗稍差點。
今天的我們這個問題解決方案就先使用這個。
不過後面我們還是改成下面這種方式。
後端集中儲存
組長：
上面幾種的方式我們都是把 Session 儲存在應用記憶體上，應用機器只要重啟，Session 就會丟失。
為了這個解決這個問題，我們將 Session 單獨存起來，儲存到 Redis 或者 MySQL 中。
不過由於 Session 需要過期失效的特性，不需要持久化儲存，所以這裡我建議使用 Redis 來儲存。
這樣架構就變成下方這樣的：
我們使用這種方案，上沒有 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。
幫助
- 架構師之路-session一致性架構設計實踐
歡迎關注我的公眾號：程式通事，獲得日常乾貨推送。如果您對我的專題內容感興趣，也可以關注我的部落格：studyidea.cn