上一篇文章聊了下session的基本原理，這兩天想了下如何更好的瞭解session，及隨著系統越來越大會碰到的問題。
這裡我們假設服務器是一家公司，那麼session就充當了看門大爺的角色。
用戶想要進入我們的公司，我們總不能隨隨便便讓人進入。這時候看門大爺就要求你記錄的個人信息，來就是來訪記錄。然而用戶可能辦完一件事就走了，等下次要辦事的時候再來。用戶一段時間內可能需要辦好幾件事，每次來都要登記就太麻煩了。這時候看門大爺就生成了一串特定的編碼（即sessionId），然後把編碼交給用戶，用戶每次過來刷一下編碼，大爺查看下這個編碼有效就放行了。當然看門大爺保存sessionId及用戶信息的方式有多種，可以記在本子上（文件存儲），如果大爺夠潮就可以記在電腦上（即內存和數據庫中，由於現在redis及memcached 越來越成熟一般都會選擇存儲在這些高性能的k-v 數據庫中）
至此我們模擬了session的基礎流程。接下來我們看看隨著用戶增加，系統越來越大，一家公司（服務器）肯定接待不過來了，是時候開分公司了（多臺服務器 或者稱為服務器集群）。假設我們原來的看門大爺是把信息都記錄在本子上的（即以文件形式存儲），這個時候一個看門大爺肯定忙不過來了。首先我們想到的是為每個公司（服務器）都配置個看門大爺（即每臺服務器都各自保存session）。這裡就出現一個問題了，假如用戶第一次來到公司A, A公司的看門大爺記錄了用戶信息，用戶辦完事離開了。後來用戶又過來辦事了，但是這次他去了公司B,然後公司B的看門大爺查他的本子，發現沒查到（因為他的記錄是在公司A的看門大爺本子上),用戶不得不又一次登記信息。那又什麼辦法解決呢？
首先想到的辦法是同步大爺本子的信息，就是A看門大爺記錄後告訴一聲B看門大爺讓他也記錄下。這種做法缺點很明顯，隨著服務器越來越多，需要同步的地方也越來越多，而且同步過程有延遲，還會佔用一定帶寬。所以雖然這是一種辦法，但是一般不會用這種辦法。
這時候一般就要升級看門大爺的技能了（看門也不是那麼好做的）。我們要求看門大爺使用網絡，把信息記錄到一個統一的服務器中（即session服務器 往往通過redis或memcached來實現）。每次用戶來信息都存到session服務器中，取也是從session服務器中取。這樣我們就解決的多個服務器（分佈式服務器）共享session的問題。
最後再說一點：單臺session服務器也存在問題，就是萬一這臺session服務器掛了，那麼我們就取不到了。解決辦法是使用主從報備，也就是多出一臺session服務器，一臺是主，一臺是從，從保持和主的同步。這樣主如果壞了，自動切換到從來進行工作。有同學可能會問怎麼自動切換啊，這裡就不詳細展開了業界已經有成熟的工具有興趣的同學可以自行查詢。
今天就聊到這，希望能給大家更深入得理解session及隨著系統擴大會出現的問題帶來幫助。喜歡的朋友麻煩點各關注，點贊支持下哦。
相關推薦
