摘  要： 用戶會話信息一致性是影響集群負載均衡的一個重要因素。在研究當前負載均衡集群系統(tǒng)中會話保持機制的基礎上，針對會話復制方法中隨著請求增加導致網(wǎng)絡阻塞的問題，提出一種添加了動態(tài)會話集中存儲設備的會話復制機制。經(jīng)模擬驗證，該方法在較大規(guī)模集群環(huán)境下穩(wěn)定響應多用戶請求，平均響應時間仍處于相對穩(wěn)定狀態(tài)，滿足大型企業(yè)級應用的會話處理需要。

　　關鍵詞： 集群；負載均衡；會話保持機制；會話復制

1 研究綜述

　　1.1 負載均衡技術

　　隨著計算機技術的發(fā)展，服務器性能成為影響大型應用系統(tǒng)的關鍵因素。Web服務器集群是通過高速局域網(wǎng)互連的多臺Web服務器組成的，用戶的HTTP請求被均衡地、透明地分配到集群中具體的服務器上，由其完成請求響應過程，并將響應結果返回給用戶[1]。在性能、可靠性、靈活性方面，服務器集群比直接升級單臺服務器有相對較高的效益。

　　集群服務器的一個重要技術是集群內(nèi)部用戶請求的均衡分配——負載均衡。負載均衡技術能夠根據(jù)各個服務器處理能力，合理地給各個服務器分配相應的請求任務，均衡分配任務的過程對用戶來說是完全透明的[2]。

　　1.2 負載均衡下的會話保持機制

　　目前，HTTP協(xié)議[3]是Web應用中使用最廣泛的應用層協(xié)議，采用分布式協(xié)作的方式和請求/響應模式的無狀態(tài)協(xié)議。Web應用不保存與任何客戶機通信的狀態(tài)，只負責對到來的當前請求進行處理，因此需要一定的機制保持會話。對于負載均衡集群，應該保證無論請求被分配到哪個節(jié)點，用戶請求對應的會話信息應該相同，實現(xiàn)節(jié)點之間的信息一致。

　　會話保持機制主要實現(xiàn)方式分為Cookie機制和會話機制。Cookie機制將用戶信息存放在客戶瀏覽器中，隨著用戶發(fā)送的請求一起傳遞給服務器。因受到請求大小的限制和安全問題，它不適合存放敏感性的用戶信息。因此，在會話保持機制中，Session機制很常用，它通過將整個用戶會話過程中保持其狀態(tài)的信息存儲在服務器端來實現(xiàn)。

　　目前LB集群系統(tǒng)中，常用的會話保持機制[4]有如下幾種：

　?。?）以負載均衡服務器入手，管理某個用戶的請求和這些請求被分配到的集群機的對應關系，通過查詢關系表，將請求分配到之前被分配到的集群機上進行服務。

　?。?）負載均衡系統(tǒng)中，在多臺服務器間根據(jù)處理需要傳遞復制會話信息，實現(xiàn)會話復制策略。用戶請求發(fā)送之后，系統(tǒng)會自動查詢是否已經(jīng)產(chǎn)生對應的會話信息，然后進行會話處理。

　?。?）從應用程序的會話管理入手，不將會話數(shù)據(jù)保存在集群機本地，而是所有集群機使用同一個會話數(shù)據(jù)緩存區(qū)，集群機通過查詢會話緩存區(qū)獲取該用戶的Session id對應的數(shù)據(jù)。

　　1.3 會話保持中的會話復制機制

　　在LB集群系統(tǒng)中，也常常采用會話復制機制維護集群中的用戶信息。會話復制機制的主要實現(xiàn)方式是：通過序列化，將存儲在內(nèi)存的會話信息轉換成可以傳輸?shù)男问?，然后通過廣播將消息傳遞給集群內(nèi)部其他節(jié)點，節(jié)點接收報文并進行相應處理，從而使集群系統(tǒng)中每個節(jié)點都存儲著同樣的會話庫。

　　這種機制的優(yōu)點是負載均衡設備對任務分配的靈活性高，系統(tǒng)的穩(wěn)定性強，具有良好的可靠性和高性能，而且不會因為出現(xiàn)單個節(jié)點故障而丟失會話信息。缺點主要是應用規(guī)模小。增加節(jié)點會造成傳遞會話復制信息的工作量加重，造成節(jié)點性能下降，引發(fā)廣播風暴。

2 改進的會話復制機制

　　會話復制機制的優(yōu)點適用于負載均衡集群。但是，對于集群規(guī)模較大的企業(yè)級應用系統(tǒng)，會話復制機制往往不合適。本次研究的主要目的是改進會話復制機制，使該機制適用于中大型企業(yè)。

　　復制會話信息消耗每個節(jié)點的內(nèi)存和網(wǎng)絡帶寬，是限制群集的規(guī)模的主要原因。進而，為了控制廣播中傳遞的會話信息量，提出將會話信息分解，穩(wěn)定的會話信息部分選擇會話復制機制，數(shù)據(jù)量大且變化大的部分采取集中存儲機制的會話機制，盡量減少在會話復制過程中復制和廣播的信息量，使會話復制機制更適用于大型應用系統(tǒng)。

　　2.1 改進方法的硬件部署方案

　　改進后的會話復制機制采用會話復制為核心，集中存儲設備為輔助。具體的服務器端的硬件部署模型如圖1所示。服務器端集群多由若干個中小型規(guī)模集群組成。負載均衡平臺的主要功能是轉發(fā)用戶請求，對任務進行分配。負載均衡器接受用戶發(fā)送的請求，針對當前系統(tǒng)中的服務器節(jié)點的狀態(tài)，均衡分配用戶的請求。負載均衡器對集群系統(tǒng)的負載均衡起到總體調(diào)控的作用。

　　集群中包含了服務器集群、數(shù)據(jù)庫集群以及系統(tǒng)備份和企業(yè)級業(yè)務。其中，企業(yè)級業(yè)務包括FTP服務、郵件服務和企業(yè)內(nèi)部管理平臺。備份服務器采用雙機備份的原則，當負載均衡設備出現(xiàn)故障時，便于系統(tǒng)的恢復。

　　為了解決會話復制過程中大量數(shù)據(jù)復制的問題，在集群結構的內(nèi)部添加了會話集中存儲設備。該設備用于存儲穩(wěn)定性較差的會話信息，對該部分數(shù)據(jù)進行統(tǒng)一的管理，采取點對點的傳遞方式，僅限于處理節(jié)點與會話存儲設備之間的不穩(wěn)定數(shù)據(jù)傳輸。

　　對于同一用戶的會話數(shù)據(jù)，根據(jù)不同的穩(wěn)定性，將用戶的會話數(shù)據(jù)劃分為靜態(tài)數(shù)據(jù)部分和動態(tài)數(shù)據(jù)部分。靜態(tài)會話數(shù)據(jù)變化不大，數(shù)據(jù)量相對較小，具有一定的穩(wěn)定性，如用戶名、系統(tǒng)參數(shù)等，采用會話復制的形式。動態(tài)會話信息包含一些隨著時間變化而改變的數(shù)據(jù)，這些數(shù)據(jù)本身具有復雜性，如購物車、表單、實時數(shù)據(jù)等。將這部分數(shù)據(jù)的處理放在處理節(jié)點和集中存儲設備上，有效地控制這部分數(shù)據(jù)傳播的規(guī)模，而且點對點的傳輸處理也減少了對集群內(nèi)部帶寬的占用。

　　2.2 機制的實現(xiàn)

　　改進后的會話復制機制，具體實現(xiàn)流程如圖2所示。

　?。?）假設用戶A訪問系統(tǒng)時，服務器端接收用戶請求，由負載均衡平臺進行任務分配處理。負載均衡器動態(tài)或靜態(tài)地監(jiān)控集群中各個節(jié)點的負載狀態(tài)，將任務分配到負載相對較低的節(jié)點上。負載均衡平臺可通過軟件或者硬件實現(xiàn)，對集群負載起到總體調(diào)控的作用。假設負載均衡器根據(jù)當前集群狀態(tài)將任務分配到節(jié)點X。

　　（2）接收到請求后，節(jié)點X會進行相應的處理。首先，服務器X從用戶請求中查詢請求數(shù)據(jù)中的會話ID。

　?、偃绻埱笾袥]有會話ID，或節(jié)點X沒有從本機會話庫中查詢到該會話ID，集群系統(tǒng)中沒有用戶A的會話信息，則節(jié)點X為用戶A創(chuàng)建對應的會話信息。在會話創(chuàng)建完成后，分離出會話中的動態(tài)數(shù)據(jù)和靜態(tài)數(shù)據(jù)。靜態(tài)會話直接通過廣播的形式發(fā)送到集群中的每臺服務器。動態(tài)數(shù)據(jù)在完成用戶請求后，再發(fā)送至動態(tài)會話集中存儲設備。

　　②如果會話庫中包含對應的會話ID，則節(jié)點X先從會話庫中得到對應的靜態(tài)數(shù)據(jù)。然后，發(fā)送動態(tài)數(shù)據(jù)請求給動態(tài)會話集中存儲區(qū)。從回復消息中，提取相應的動態(tài)會話數(shù)據(jù)。服務器X將動態(tài)數(shù)據(jù)和靜態(tài)數(shù)據(jù)結合在一起，得到用戶完整的會話信息。

　?。?）經(jīng)過第（2）步得到完整的會話信息后，處理用戶的請求，根據(jù)請求的內(nèi)容進行相關處理，將處理結果返回給用戶。處理結果中包含會話ID，服務器將會話ID作為Cookie的一個屬性發(fā)送給客戶端，用戶后續(xù)訪問將自動攜帶該Cookie屬性。

　?。?）任務完成后，服務器中存儲的該用戶動態(tài)會話信息可能發(fā)生改變。這時服務器X需要向動態(tài)會話集中存儲設備發(fā)送存儲/更新動態(tài)會話數(shù)據(jù)的命令，存儲/更新對應的動態(tài)會話數(shù)據(jù)信息。若設備中沒有該會話ID，則直接存儲新用戶的動態(tài)數(shù)據(jù)。根據(jù)處理后的會話信息中靜態(tài)數(shù)據(jù)是否改變，決定是否發(fā)送廣播消息。

　　這種模式下，服務器處理完用戶請求后，一般的數(shù)據(jù)處理中，靜態(tài)數(shù)據(jù)具有穩(wěn)定性，廣播一次就能實現(xiàn)同步。更新的動態(tài)數(shù)據(jù)需要從處理節(jié)點發(fā)送到動態(tài)數(shù)據(jù)管理設備進行存儲，由集中數(shù)據(jù)管理器進行存儲處理。

3 模擬驗證

　　為了驗證改進后Session復制算法的性能，使用同一應用系統(tǒng)分別采用不同的會話支持技術進行比較分析。在模擬過程中，應用系統(tǒng)采用“青島某服裝企業(yè)供應鏈系統(tǒng)”，搭建的集群環(huán)境采用八臺處理機，其中一臺為主服務器，作負載均衡器。采用Tomcat進行服務器集群及負載均衡。Session集中存儲設備的大小配置為256 GB（根據(jù)需要更改大?。?/p>

　　如表1所示，采用tomcat集群中復制模式（會話復制）、Session集中存儲模式和包含動態(tài)Session集中存儲區(qū)的會話復制方式進行性能比較。

　　模擬結果如圖3所示，在初始階段，處理性能都很高。當用戶請求增加到一定數(shù)量時，服務器的性能下降，傳統(tǒng)會話復制機制會因節(jié)點間傳遞信息量的劇增導致響應時間增大。會話集中存儲方式下，因節(jié)點等待訪問存儲用戶數(shù)據(jù)，響應時間相對改進后的算法較長。動態(tài)會話集中存儲下的會話復制模式由于查找會話ID以及廣播數(shù)據(jù)量相對較少，雖然加重了節(jié)點對會話數(shù)據(jù)的處理，但隨著用戶訪問量的增多，系統(tǒng)處理效率仍處于相對穩(wěn)定的狀態(tài)。

　　綜上所述，動態(tài)會話集中存儲下的會話復制模式在平均響應時間比較穩(wěn)定地增長、系統(tǒng)訪問量劇增時，系統(tǒng)處理性能仍然穩(wěn)定，適用于節(jié)點數(shù)目相對較大的集群系統(tǒng)。

4 結束語

　　針對會話復制方法無法適應大規(guī)模集群系統(tǒng)的問題，提出了動態(tài)會話集中存儲的會話復制機制，將靜態(tài)會話數(shù)據(jù)采取會話復制策略，而動態(tài)部分采取集中存儲的策略，進而滿足負載均衡系統(tǒng)中會話一致的要求。經(jīng)實驗驗證，該方法可靠性好，性能穩(wěn)定，可滿足大型應用平臺的會話需求。如何提高動態(tài)會話集中存儲下的會話復制方法的穩(wěn)定性是之后的研究重點。

　　參考文獻

　　[1] 郭成城，晏蒲柳.一種異構Web服務器集群動態(tài)負載均衡算法[J].計算機學報，2005，28（2）：179-184.

　　[2] 陳一驕，盧錫城，時向泉，等.一種面向會話的自適應負載均衡算法[J].軟件學報，2008，19（7）：1828-1836.

　　[3] 趙章界，余智華，張丙奇.HTTP協(xié)議流解析系統(tǒng)的設計與實現(xiàn)[J].計算機工程，2005，31（24）：38-40，46.

　　[4] 趙涓涓，劉濤，強彥，等.云計算中基于Session和內(nèi)容等級的數(shù)據(jù)庫請求分類算法[J].計算機科學，2013（2），40：177-179.