Session丟失及nginx解決這個問題的方案

下文給大家帶來什么是Session丟失及nginx解決這個問題的方案，希望能夠給大家在實際運用中帶來一定的幫助，負載均衡涉及的東西比較多，理論也不多，網上有很多書籍，今天我們就用億速云在行業內累計的經驗來做一個解答。

        這篇是《分布式關注點系列》中「負載均衡」相關的內容最后一發了，后續也會繼續講「高可用」相關的其它主題，主要是限流、降級、熔斷之類的吧，具體還沒定。文末先附上之前發過的高可用相關文章，供你再溫故一下。

        下面這個場景不知是否在你面前出現過。

開發Z哥對運維Y弟喊：“Y弟，現在系統好卡，剛上了一波活動，趕緊幫我加幾臺機器上去頂一下。”

 

Y弟回復說：“沒問題，分分鐘搞定”。

 

然后就發現數據庫的壓力迅速上升，DBA就吼了：“Z哥，你丫的搞什么呢？數據庫要被你弄垮了”。

 

然后客服那邊接框也爆炸了，越來越多的用戶說剛登陸后沒多久，操作著就退出了，接著登陸，又退出了，到底還做不做生意了。

        這些問題背后都是由于一個「Session丟失」問題導致的。

一、什么是Session丟失

        相信Session對大部分Coder來說應該都知道。它是為了將同一個用戶的多次訪問在系統中被識別為“同一個用戶”而產生的概念。除此之外，還可以基于它來減少重復往DB或者遠程服務處獲取與該用戶相關的信息，以起到提升性能的作用。

        在我們做了負載均衡的場景中，如果選擇的負載策略是hash策略，那么會使得Session產生一個副作用，這個副作用就如上面舉的案例那樣，用戶一旦由于某種原因從原先訪問云服務器A變成訪問服務器B，就會出現“登陸狀態丟失”、“緩存穿透”等問題。

        為什么hash策略會出現這個問題呢？首先有必要先了解一下hash是如何進行的。hash策略就是下圖這樣的一個散列函數。在函數不變的情況下，A永遠對應01，B對應04，C對應08。

▲圖片來源于網絡，版權歸原作者所有

        以nginx中的ip_hash策略來舉個例子。因為我們認為正常情況下用戶的ip不會在短時間內發生變化，所以當我們選擇使用ip_hash策略進行負載均衡時，意味著期望同一個用戶能夠一直訪問到同一臺服務器上，就像下圖這樣。

▲圖中的hash函數是最簡單的隨意舉例

        如此一來，我們只需要在這一臺服務器上將這個用戶相關的信息緩存在進程內，就能起到非常高性價比的提升性能的效果。

        這時，客戶端與服務端之間的相當于建立了一個信任，相互認識。這個信任就是「Session」。

        但是，當我們加了一臺服務器之后，事情就發生變化了。

▲圖中的hash函數是最簡單的隨意舉例

        這個時候我們原先的預期就被破壞了。因為用戶與序號0節點的鏈接變成了與序號3的鏈接，所以產生了前面提到的「Session丟失」問題。與此同時，在序號0節點上做的進程內緩存都無效了，而在序號3節點上又沒有用戶相關的任何緩存，導致大量數據需要從下游的DB或者遠程服務處獲取。你要知道，一旦涉及到網絡通信，性能必然明顯下降，I/O、序列化都是耗時的工作。更重要的是，一旦同時有大量用戶產生這個情況，由于后端的DB和遠程服務瞬時無法承載激增的高密度請求，可能會導致它掛起。這還沒完，如果當前程序沒有一些故障隔離或者降級策略，還會進一步產生蝴蝶效應，導致整個大系統響應緩慢。可謂“一顆老鼠屎壞了一鍋粥”。

二、nginx是如何來解決這個問題的

        既然以nginx舉例，還是從nginx開始聊。通過在nginx中引入nginx-sticky-module模塊可以來解決這個問題。解決的整個過程如下。

▲圖片來源于網絡，版本歸原作者所有

        可以看到，當client第一次進入到nginx匹配節點的時候，在給它分配一個節點的同時，會將這個節點的唯一標識進行md5后寫入到cookie中一并返回，如果下次再發起請求的時候發現帶有這個cookie值，就直接轉發到該值所對應的節點上去。這個機制被專業的稱之為「Session保持」。

        雖然可以利用cookie來解決這個問題，但是cookie也有一個潛在的問題，如果客戶端未開啟cookie功能，這個機制就失效了。不過好在目前主流瀏覽器都是默認打開cookie的。

題外話：nginx是2004年發布的，在nginx-sticky-module出現之前的7年間也是nginx相比競品HAProxy最大的一個短板，因為HAProxy支持Session保持。

三、Session保持的其它方案

        除了cookie之外，還有2種方式也可以最終達到類似的效果。分別被稱為「Session復制」、「Session共享」。

01  Session復制

        這是最簡單粗暴的方式。根據第一節的案例來看，導致問題的原因是節點3沒有用戶的Session。那么很容易想到，在節點3運行之前把Session相關的Cache數據復制過去唄。并且在多個節點之間持續保證數據的同步，也就是說，每一臺節點上都存在每個用戶的Session數據。

        實現的方案有很多，特別是不同的宿主程序都或多或少提供了一些切入點，甚至是拿來即用的方案，如Tomcat的Delta Manager和Backup Manager、Tomcat和IIS的Filter機制等等，這里就不展開了。

        此類方案的特點是

• 優點：天然高可用，一部分節點宕機沒事。因為每一個節點上存放著所有已連接用戶的會話信息。

• 缺點：因為每臺計算機的內存是有上限的，僅適用于會話相關的數據大小較小的場景。并且，由于多個節點之間需要同步數據，需要額外解決數據一致性問題。與此同時，隨著節點越多，損耗越大（延遲、帶寬等），有廣播風暴風險。

02  Session共享

        我們還可以通過將session信息存放到全局共享的存儲介質中來達到一樣的效果，如數據庫、遠程緩存等，這是一種中心化思想的解決方案。

        此類方案的特點是

• 優點：不管節點怎么增加和減少，100%不會產生會話丟失。

• 缺點：每次讀寫請求都需要增加額外共享儲存調用，增加了網絡I/O、序列化等操作，性能明顯下降。另外，用作共享的存儲介質除了增加了額外的維護成本外，還需要解決單點問題，以免產生系統性風險。

        同之前「Session保持」方案一起對比下各自的優缺點和適用場景。

        分別用一句話概括一下這3個方案：

• Session 保持。原來在哪還是去哪。

• Session 復制。不管在哪都有一樣的數據。

• Session 共享。所有節點共用一份數據。

        越大型的系統，最終都會往「Session共享」這個方案上走，因為只要再對這個共享存儲做橫向擴展，理論上就可以支撐無窮大的用戶了。如Redis、一系列的NOSQL以及NEWSQL等。就像下面這樣，集「規模大」、「高可用」、「效果好」于一身。

看了以上關于Session丟失及nginx解決這個問題的方案，如果大家還有什么地方需要了解的可以在億速云行業資訊里查找自己感興趣的或者找我們的專業技術工程師解答的，億速云技術工程師在行業內擁有十幾年的經驗了。