陳大才,呂 立,高 岑,孫 詠

1(中國科學院大學,北京 100049)

2(中國科學院 沈陽計算技術研究所,沈陽 110168)

1 引言

互聯(lián)網(wǎng)的高速發(fā)展使得上網(wǎng)用戶劇增,很多互聯(lián)網(wǎng)服務的日活躍量成指數(shù)增長.這就給服務器帶來了巨大的壓力.服務器必須升級以服務更多的用戶.同時,近幾年互聯(lián)網(wǎng)越來越多的新“玩法”給服務器的并發(fā)訪問能力帶來了嚴峻的挑戰(zhàn).比如微信搶紅包、淘寶雙十一、春運搶票等.2016年除夕夜發(fā)的紅包數(shù)量就達到了幾十億個.對承載這些秒級數(shù)據(jù)和高并發(fā)響應的的服務器的性能的需求可想而知[1].

如何提高服務器的并發(fā)訪問能力還是一個值得深入研究的課題.本文通過提出一種新型的負載均衡策略來提高服務器集群的整體處理效率,從而提高Web服務器的并發(fā)訪問能力.

2 研究現(xiàn)狀

多年來,負載均衡一直是服務端一個熱門的話題,新的策略和解決方案不斷的被提出,已經(jīng)從最初的只能通過靜態(tài)設置,到后來的可以根據(jù)集群運行情況作出動態(tài)分配,再到最后的自適應策略等.已經(jīng)有很多的相關技術人員作出了不可磨滅的貢獻[1].其中,國外的許多企業(yè)和研發(fā)團隊推出了很多較好的解決方案.Microsoft公司針對于集群的負載情況,提出了具有較高可伸縮性和可用性的網(wǎng)絡負載均衡技術(NLB)以及基于作用在多層集群網(wǎng)絡的中間件與網(wǎng)絡負載均衡的組件負載均衡技術(CLB)[2].IBM公司推出的Web Sphere[3]相關的一套強大的Web 應用服務器,其提供了優(yōu)秀的集群解決方案以及卓越的負載均衡功能.Intel公司網(wǎng)擎系列中的負載均衡器采用的快速響應算法[4].在國內,諸多高校也在致力于研究負載均衡策略,例如清華大學、國防科學技術大學、浙江大學等,其中具有代表性的有清華大學研發(fā)的可擴展的Web服務器集群系統(tǒng),國防科技大學章文嵩博士主持開發(fā)的Linux虛擬服務器項目等[5].

3 最少響應時間負載均衡策略

本文提出的算法根據(jù)當前請求的請求類型計算出當前每個服務器節(jié)點預計的響應時間,并從中選擇一個擁有最少響應時間的節(jié)點,用該節(jié)點處理請求.

本算法適用于具有負載調度器、業(yè)務服務器池和共享存儲三層結構的負載均衡集群結構[6].

為了簡化模型,本文假設集群中的所有服務器節(jié)點都具有相同的硬件和軟件配置.

3.1 相關概念

負載調度器:負載均衡集群結構中用來接收用戶請求并向后端服務器節(jié)點分發(fā)請求的節(jié)點.

業(yè)務服務器:用于實際業(yè)務操作的服務器.

請求:用戶發(fā)送的 HTTP Request,如登錄請求、注冊請求等.

請求類型:請求的動作,如登錄、注冊、購買商品等.響應:服務器處理完用戶請求后,反饋的結果.

請求處理時間:服務器從請求隊列中抓取請求進行處理,并處理完成的時間.

請求響應時間:請求從負載調度器發(fā)出后,直至接收到響應所需要時間.

3.2 影響響應時間因素的分析

在集群結構中,影響單節(jié)點中響應時間的因素大致有以下幾種:

(1)當前服務器節(jié)點的性能情況[1]

如 CPU 、內存、磁盤 IO、網(wǎng)絡帶寬情況.

當前節(jié)點的性能決定了請求的處理時長.

(2)請求類型

不同類型的請求所需要做的操作步驟不同(如有的請求查詢數(shù)據(jù)庫較多,有的數(shù)學計算較多),所需要的資源也不同(如 CPU 密集型任務需要更多的處理機資源,IO 密集型任務需要更多的 IO 資源),進而所需要的處理時間也不同.

例如登錄請求所做的操作一般比獲取用戶資料多,也更耗費時間.

(3)請求隊列的總響應時間

即當前請求隊列中的所有請求都被處理完所需要的時間.

當前請求隊列的總響應時間決定了新請求多長時間之后才能被處理.

經(jīng)過上面的分析,本文提出了一種算法,通過使用以往的實際請求響應時間及節(jié)點的負載情況等歷史數(shù)據(jù)進行建模,然后預測新請求的響應時間,從而選擇具有最少響應時間的服務器節(jié)點來處理請求,達到所有請求都近似擁有最少響應時間的目標,最終集群的總響應時間就減少了.

3.3 算法描述

給每個服務器節(jié)點設置以下變量:

(1)當前性能情況P

(2)預估處理等待時間Tw

用于標記新請求可能需要等待多長時間才能被處理.

(3)預估響應時間Rp

給每個請求設置以下變量:

(1)請求類型 Action 參數(shù)A

(2)請求的開始響應時間Rstart

(3)請求的實際響應時間Rr

(1)提取請求中的請求類型[7]

負載調度器收到用戶發(fā)送的請求,提取出其中的請求類型參數(shù)A.

(2)預測各節(jié)點的響應時間

將請求類型參數(shù)A、各節(jié)點的當前性能情況信息P和各節(jié)點的預估處理等待時間Tw輸入響應時間預測模型中得出每個服務器節(jié)點預估的響應時間.

(3)選擇具有最少響應時間的服務器節(jié)點

負載調度器從上一步計算出的各節(jié)點預估響應時間中選擇一個具有最少響應時間的服務器節(jié)點,并更新該節(jié)點的Rp值,將請求發(fā)送給該服務器節(jié)點,并記錄該請求的開始響應時間Rstart.

(4)處理請求并記錄實際響應時間

服務器節(jié)點收到請求后,將請求放入請求隊列中.服務器節(jié)點從請求隊列中選取一條請求進行處理.處理完成后,在響應頭中添加當前服務器節(jié)點的性能情況信息P′作為響應頭,并將響應回傳給負載調度器.

(5)使用實際響應時間矯正響應時間預測模型

負載調度器用收到響應時的當前時間Tn減去第 2步記錄的開始響應時間Rstart,得到該請求的實際響應時間Rr.負載調度器將該實際響應時間Rr和第 2 步記錄的A、P、Tw放入響應時間預測模型中,對預測模型進行校正.

(6)更新預估處理等待時間Tw

更新預估處理等待時間為Tw=Rp–Rr,其中Rp等于服務器節(jié)點中當前請求隊列中最末尾的一條記錄的預估響應時間;Rr等于最近收到響應的請求的實際響應時間,也就是請求隊列中剛處理完的請求的實際響應時間.兩者之差就是當前請求隊列的總響應時間.

(7)記錄結點當前負載情況

負載調度器從收到的響應頭中提取結點的當前負載情況P′,更新變量P.

(8)給用戶發(fā)送響應

負載均衡器從響應頭中刪去負載均衡算法使用的信息,并將響應發(fā)送給用戶.

圖1 集群結構

3.4 提取請求中的請求類型

當負載調度器接收到由用戶發(fā)送過來的請求時,負載調度器會從請求中提取請求類型.

例如,從請求 http://www.example.com/login?userID=123456&pwd=s2a51s&timestamp=1400&verify=s45 f83f 中可以提取其請求類型為 login;從請求 http://www.example.com?action=signup&userID=123456 中可以提示其請求類型為 signup.

3.5 響應時間預測模型

本算法通過使用機器學習算法建立響應時間預測模型來預測請求的響應時間.

通過 3.2 節(jié)的分析,本算法使用請求類型A、服務器節(jié)點的性能情況P、請求隊列的總響應時間Tw作為輸入?yún)?shù),用請求響應時間Rp作為輸出參數(shù).即有如下模型:

為了方便實驗,本文只選用了 CPU 占用率、內存剩余量、磁盤 IO 讀寫速度、網(wǎng)絡讀寫速度等簡單的性能參數(shù).為了方便機器學習,以上參數(shù)都使用標準化算法將他們轉換到一個數(shù)值范圍內.

為了減少負載調度器的計算開銷,將模型的訓練階段的計算任務放到一個單獨的計算機中進行,稱之為模型訓練節(jié)點.模型訓練節(jié)點將模型訓練好之后通過網(wǎng)絡將結果發(fā)送給負載調度器,負載調度器用它來預測響應時間.

3.6 減少負載調度器的計算開銷

本算法為了提高任務調度的均衡性,給負載調度器增加了不少的額外計算開銷,而如果系統(tǒng)的額外開銷大于系統(tǒng)的優(yōu)化,那么很容易進一步增加集群的負載.本算法的細節(jié)設計部分采用了以下幾種方法進行優(yōu)化,以更大程度的減少負載調度器的計算開銷:

(1)將模型建立過程的計算任務放到一個獨立于負載調度器之外的計算機中執(zhí)行,這樣降低了負載調度器的計算量.

(2)當處理完成的請求數(shù)達到一定數(shù)量后才矯正一次模型,而不是每一次處理完請求后都要矯正響應時間預測模型,減少了頻繁訓練模型帶來的計算量[8].

(3)隨著系統(tǒng)運行時間的增加逐漸增大矯正模型的請求量閾值.

當系統(tǒng)運行足夠長時間之后,模型就變得非常穩(wěn)定了,所以就不需要頻繁矯正模型了.

4 實驗驗證

4.1 實驗環(huán)境

本文所使用的實驗環(huán)境如下:

(1)服務器節(jié)點

數(shù)量:16;硬件:6G 內存/2 核 4 線程 3.2 GHz CPU;軟件:CentOS 7 + Tomcat 8 + Redis + MySQL + kafka +商品秒殺系統(tǒng)(業(yè)務系統(tǒng)).

(2)負載調度器

數(shù)量:1;硬件:8G 內存/4 核 8 線程 3.3 GHz CPU;軟件:CentOS 7 + Nginx[8,9]1.12 + 本文所講述的負載平衡算法模塊.

(3)模型訓練節(jié)點

數(shù)量:1;硬件:4G 內存/2 核 4 線程 2.2 GHz CPU;軟件:CentOS 7 + Python3 + Scikit-learn.

(4)用戶端

數(shù)量:2;硬件:4G 內存/2 核 4 線程 2.2 GHz CPU;軟件:CentOS 7 + Java8 + JMeter.

4.2 實驗過程

本實驗使用JMeter[3]模擬用戶的高并發(fā)訪問請求;用商品秒殺系統(tǒng)作為實驗中的基準測試程序,該系統(tǒng)擁有完整的用戶登錄、注冊、管理模塊和商品瀏覽、搶購模塊;使用Scikit-learn[3]運行機器學習程序.

本實驗通過設置不同的并發(fā)量、不同的機器學習算法(決策樹 CART、向量機、KNN等算法)[10]、不同的服務器節(jié)點(4節(jié)點集群、8節(jié)點集群和16節(jié)點集群)來進行不同組的實驗,采用傳統(tǒng)的 URL散列算法作為對照組,得出實驗結果如圖2.

圖2 實驗結果

從實驗結果可以看出,本算法適用于小規(guī)模集群、高并發(fā)請求的場景.對于小集群、低并發(fā)請求和大集群高并發(fā)的情況,負載調度器的額外開銷超過了系統(tǒng)的優(yōu)化,增加了系統(tǒng)的平均響應時間;而小集群、高并發(fā)請求的情況下,由于集群中服務器節(jié)點的性能是集群中的性能瓶頸,本算法優(yōu)化了任務調度來均衡各服務器節(jié)點的性能,提高了集群的效率,降低了系統(tǒng)的平均響應時間.

5 總結

本文通過使用機器學習算法建立了響應時間預測模型對請求的響應時間進行預估,并使用最少響應時間策略進行負載調度,提高了小集群高并發(fā)場景下系統(tǒng)的效率.通過實驗驗證了本算法對減少集群的平均響應時間具有一定的效果.