一．什麼是會話？

使用者在使用我們的服務時，要使用一個功能，往往在客戶端和我們的服務端中間需要進行多次的通訊和互動。這裡一個使用者和服務端系統進行互動通訊的過程就叫做一次會話。而http協議本身是無狀態的，即服務端每次都會響應客戶端的請求，但是不會記得是哪一個客戶端發起的請求。為了識別不同的請求是否來自同一客戶，引用HTTP會話機制，即：多次HTTP連線間維護使用者與同一使用者發出的不同請求之間關聯的情況稱為維護一個會話（Session）。

舉個例子：使用者登入一個App，需要輸入一次登入密碼完成登入，登入完成以後進去App裡面使用功能，到使用者主動退出App可以看作一次會話。從使用者登入到退出的過程中，使用者可能在App裡面做很多操作，在客戶端和服務端的這麼多次互動中，怎麼確定一直是同一個使用者呢， 基於Cookie和Session的會話控制機制就是解決這個問題。

Cookie和Session，簡而言之Cookie是儲存在客戶端中的資料，我們通過Cookie來跟蹤與儲存使用者資料。Session是將使用者的會話資料儲存在服務端。通過比對cookie和Session中的資料來完成會話控制。詳細的Cookie和Session的區別和聯絡網上介紹的文章很多，這裡不再贅述。今天主要介紹一下分散式系統下的Session的儲存問題。

二．分散式系統下的Session的儲存問題以及解決思路。

參看圖1，Session儲存在應用伺服器上，當第一次使用者的請求落在A伺服器，Session也儲存在A，如果在負載均衡伺服器不做處理，就不能保證下一次使用者在的請求還是落在A，這樣Session校驗失敗，會話就可能會失效，使用者就需要重新登入App。

解決這個儲存問題的思路一般可以有以下幾種。

• 負載均衡伺服器處理

如圖2所示。這是最簡單的方案，通過做標記，我們確保每一個Session的請求都一定能夠落到同一個服務端上進行處理，Session進行應用伺服器的本地化儲存非常方便，這種方案裡面，對單個使用者來說實際上伺服器還是一種單機模式，所以也帶來了幾個問題：

1. 叢集模式失效，單個使用者每次的請求只能由一個伺服器進行處理，該伺服器宕機或者重啟，該機器上的所有會話資料丟失，和分散式叢集的高可用初衷相違背。
2. 負載均衡器變為了一個有狀態的節點，要儲存會話和具體的伺服器的對映關係，記憶體消耗大，容災難度大

• Session資料同步

如圖3所示，這個方案主要做的就是在應用伺服器之間做Session資料的同步。即每個應用伺服器都儲存了全部使用者的會話資料。好處是負載均衡器恢復了無狀態，不再儲存對映關係，使用者的請求也可以任意落到某一應用伺服器。這種方案也有它的侷限性：

1. 同步Session資料需要非常大的網路開銷，而且維護同步資料的邏輯也很複雜，牽一髮而動全身。
2. 單機儲存會話資料記憶體佔用過高。使用者量越大機器數量越多，每個機器需要儲存的資料就越多。且每臺機器都是儲存的重複資料。

• 資料庫集中儲存

方案3也是在方案2思路上進行的優化，如圖4所示，我們將Session資料儲存在資料庫中。

可以看到在資料庫集中儲存的方案中，負載均衡伺服器同樣是無狀態的節點，且使用者的請求也不用固定在某一特定的應用伺服器上。但是沒有了資料的同步和複製。我們通過集中儲存的方式，將Session資料的增刪改查集中到了一個地方。尤其是在如今使用者量大，伺服器多，併發高的場景中，Session資料集中儲存的有點非常明顯。在儲存的資料庫選擇上，可以選擇關係型資料庫 如MySql，Oracle等，也可以選用非關係型資料庫如Redis，Memcache等。

三．分散式系統會話控制系統設計

在移動應用場景中，為了兼顧使用者體驗與安全性，很少有應用需要使用者每次使用App時都進行一次登入密碼的輸入和校驗操作。大部分應用都通過各種各樣的形式如手勢登入，指紋登入等方式，甚至免登入的方式降低使用者進入App的門檻。在分散式集群系統中，怎麼實現免登入，又能讓服務端安全快捷的標識客戶端，這個對會話控制系統的設計提出了不小的挑戰。

我們可以採用會話憑證分級的方式，密碼登入可以換取長期有效的會話憑證Token， Token可以換取短期有效的會話臨時憑證TempToken。會話憑證具體的儲存以及使用 方式如下表1：

所以免登入的實現方式是，在使用者首次密碼登入成功以後，將換取的Token儲存在客戶端，下次再喚起App時，客戶端和服務端做一次互動，校驗Token的有效性。校驗通過則換取TempToken，使用者可以進入App。TempToken即可作為這次喚起App的會話控制憑證。

架構設計如下圖5：