應用伺服器叢集的Session管理（上）

應用伺服器的高可用設計主要基于服務無狀态這一特性，但事實上，業務總

是有狀态：

在電商網站，需要有購物車記錄使用者的購買資訊，使用者每次購買請求都是向購物車中增加商品

在社交類網站，需要記錄使用者的目前登入狀态、最新釋出的消息及好友狀态等，使用者每次重新整理頁面都需要更新這些資訊

Web 應用中将這些多次請求修改使用的上下文對象稱作會話(Session)。單機情況下，Session 可由部署在伺服器上的Web 容器( 如Tomcat) 管理。

在使用負載均衡的叢集環境中，由于負載均衡伺服器可能會将請求分發到叢集中的任何一台應用伺服器上，是以保證每次請求依然能夠獲得正确的Session比單機時要複雜很多。

叢集環境下,Session 管理主要有以下幾種手段：

1 Session 複制

早期系統使用的一種伺服器叢集Session管理機制。應用伺服器開啟Web 容器的Session複制功能，在叢集中的幾台伺服器之間同步Session對象，使得每台伺服器上都儲存所有使用者的Session資訊,這樣任何一台機器當機都不會導緻 Session 資料丢失，而伺服器使用Session時，也隻需在本機擷取。

1.1 優點

雖然簡單,從本機讀取Session資訊也很快速,但隻能使用在叢集規模比較小的情況下

1.2 缺點

• 當叢集規模較大時,叢集伺服器間需要大量的通信進行Session複制,占用伺服器和網絡的大量資源,系統不堪負擔
• 而且由于所有使用者的Session資訊在每台伺服器上都有備份,在大量使用者通路的情況下,甚至會出現伺服器記憶體不夠Session使用的情況

而大型網站的核心應用叢集就是數千台伺服器,同時線上使用者可達千萬,是以并不适用這種方案

2 Session綁定(黏滞sticky)

可利用負載均衡的源位址Hash算法實作。

負載均衡伺服器（比如 nginx）總是将來源于同一IP的請求分發到同一台伺服器上(也可以根據Cookie資訊将同一個戶的請求總是分發到同一台伺服器上，當然這時負載均衡伺服器必須工作在HTTP 協定層)。這樣在整個會話期間，使用者所有的請求都在同一台伺服器上處理，即Session綁定在某台特定伺服器上，保證Session總能在這台伺服器上擷取

• 利用負載均衡的會話黏滞機制将請求綁定到特定伺服器

• 

• 

• 但是Session綁定的方案顯然不符合我們對系統高可用的需求。

缺點

一旦某台伺服器當機,那麼該機器上的Session也就不複存在了,使用者請求切換到其他機器後因為沒有Session而無法完成業務處理

是以雖然大部分負載均衡伺服器都提供源位址負載均衡算法,但很少有網站利用這個算法進行Session管理。