你知道大型網站是如何做負載均衡的嗎：大型網站負載均衡解決方法(2)

會話狀態管理

在完整的用例 中，應用程序通常需要在各個步驟之間與用戶交互。在用戶實現其目標的過程中，他們在交互時所作的每個響應會影響可供用戶使用的選項和應用程序的狀態。術 語"會話狀態"通常用于描述這種以用例為中心的狀態。此會話狀態的一部分僅僅用于跟蹤任務的進度，并在使用結束后丟棄該部分;如果用例成功結束，則將會話 狀態的其他部分保存在數據庫中進行長期存儲。例如，在使用聯機購物車的用戶選擇結帳按鈕(購物車中至少有一個項目時，才會啟用該按鈕)之前，很少要求該用 戶提供支付或運送信息。

分布式應用程序通常通過網絡連接調用遠程服務器上的軟件組件。應用程序必須跟蹤在各步驟之間會話狀態發生的更改，以提供它們之間的連續性。應用程序設計人員通常在以下三個基本位置中的某一個維護會話狀態：

•客戶端。應用程序設計人員將每個用戶的會話狀態存儲在用戶的計算機上。

•中間服務器。應用程序設計人員將會話狀態存儲在一臺在客戶端計算機與永久存儲用戶信息的數據庫服務器之間作為中介的計算機上。

•數據庫服務器。應用程序設計人員將會話狀態與其他長期應用程序和用戶數據一起存儲在數據庫服務器中。

只有中間服務器方法影響此模式。每種方法及其優缺點在 Designing for Scalability with Microsoft Windows DNA [Sundblad00] 的第 2 章"Designing for Scalability"中有詳細說明。

如果所有服務器都是無狀態的(就是說，在服務器處理請求后，服務器的狀態將還原為默認值)，一個簡單的解決方案(如圖 1 中所示的解決方案)就足夠了。在兩種情況下服務器可以是無狀態的。其一，客戶端不需要會話;也就是說，每個請求都是單獨的工作單元，并且在請求之間沒有持 續存在的臨時值。其二(稱為"客戶端會話管理")，客戶端本身將保存會話的狀態，并在請求內發送會話狀態信息，以便任何服務器都可以檢查到請求，并繼續處 理它。

在服務器會話管理方案中，服務器負責維護用戶會話的狀態。服務器會話管理要求負載平衡器將同一個用戶會話內來自一個客戶端的所有請求定向到同一個服務器實例。此機制通常稱為"服務器關系"。

會話管理本身的一個問題是：如果服務器因出現錯誤或進行維護而脫機，則可能會丟失客戶端的工作，而且客戶端必須重新發送丟失的會話中已經發送的所有 請求。在某些情況下，偶然丟失會話對用戶來說不是大問題。例如，在聯機地圖搜索應用程序中，如果服務器丟失用戶剛鍵入的地址，用戶重新鍵入該地址不會是一 件太麻煩的事情。但是，在其他情況下，會話丟失可能是極其不便的。例如，在具有無狀態客戶端的聯機租用應用程序中，用戶可能要花費 10 分鐘的時間才能將幾頁有價值的信息鍵入到合約表格中。如果負載平衡組中的一臺服務器脫機，您當然不希望用戶再花費 10 分鐘重新鍵入所有信息。為避免因負載平衡組中的服務器出現故障而導致的會話丟失，可以使用以下兩種方法：集中式狀態管理和異步會話狀態管理。圖 2 顯示集中式狀態管理。

圖 2:負載平衡和集中式狀態管理

集中式狀態管理方法將會話狀態信息存儲在一臺與應用程序服務器處于不同層的集中式服務器上。應用程序服 務器每次收到作為會話一部分的請求時，它先從會話管理服務器提取會話狀態，然后處理該請求。會話管理服務可以是運行在存儲了共享資源并且具有高可靠性配置 的服務器上的數據庫或另一類型的應用程序。有關如何改進共享資源上的容錯的詳細信息，請參閱 Failover Cluster 模式。

圖 3 顯示異步會話狀態管理。

圖 3:負載平衡和異步會話狀態管理

使用異步會話狀態管理方法時，每臺服務器只要發生會話狀態更改，就會將其會話狀態廣播給所有其他服務 器;因此，每臺服務器都包含所有會話的狀態信息，而且任何服務器都可以處理包含在會話中的請求。會話狀態還會在單獨的服務器出現故障之后繼續存在。因為不 需要額外的設備，所以此解決方案更經濟;但是，因為它涉及異步調用，所以其配置和維護更困難。在每臺服務器上存儲所有會話的狀態還會導致效率更低。

原文轉自：http://blog.sina.com.cn/s/blog_c34954a30101tkhl.html