應用伺服器集群的Session管理

應用伺服器的高可用架構設計主要基於服務無狀態這一特性，但是事實上，業務總是有狀態的。

在交易類的電子商務**，需要有購物車記錄使用者的購買資訊，使用者每次購買請求都是向購物車中增加商品；

在社交類的**中，需要記錄使用者的當前登入狀態。

web應用中將這些多次請求修改使用的上下文物件稱作會話（session），單機情況下，session 可由部署在伺服器上的web容器管理。在集群環境下，由於負載均衡伺服器可能會將請求分發到集群中任何一台應用伺服器上，所以保證每次請求依然能夠獲得正確的session 比單機時要複雜的多。

集群環境下，session 管理的主要手段有以下幾種：

接下來，我們逐一進行介紹。

在伺服器之間進行 session 同步操作，每個伺服器都有所有使用者的 session 資訊，因此使用者可以向任何乙個伺服器進行請求。

缺點：

session 繫結（sticky session），又叫會話粘滯。需要配置負載均衡器，使得乙個使用者的所有請求都路由到同乙個伺服器，這樣就可以把使用者的 session 存放在該伺服器中。（這時負載均衡伺服器必須工作在http協議層上，比如反向**負載均衡）

缺點：

當伺服器宕機時，將丟失該伺服器上的所有 session。

使用乙個單獨的伺服器儲存 session 資料，可以使用傳統的 mysql，也使用 redis 或者 memcached 這種記憶體型資料庫。由這個 session 伺服器統一管理 session。

這種解決方案事實上是將應用伺服器的狀態分離，分為無狀態的應用伺服器和有狀態的session 伺服器，然後針對這兩種伺服器的不同特性分別設計其架構。

優點：為了使得大型**具有伸縮性，集群中的應用伺服器通常需要保持無狀態，那麼應用伺服器不能儲存使用者的會話資訊。session server 將使用者的會話資訊單獨進行儲存，從而保證了應用伺服器的無狀態。

缺點：需要去實現訪問 session 的**。

《大型**技術架構》- 李智慧型著

文章插圖也均源自此書