曹衛(wèi)東，孫曉君，周 原，王 靜

(1.中國民航大學(xué) 計算機(jī)科學(xué)與技術(shù)學(xué)院, 天津 300300； 2.中國民航大學(xué) 天津市智能信號與圖像處理重點(diǎn)實(shí)驗室，天津 300300)

0 引 言

逐年增長的航空旅客運(yùn)輸量產(chǎn)生大量的訂票需求，新一代旅客服務(wù)系統(tǒng)(passenger service system，PSS)等大規(guī)模分布式集群系統(tǒng)能夠共同分擔(dān)海量用戶請求，其上部署的負(fù)載均衡算法可以提供一種有效透明的方法，提高集群系統(tǒng)中服務(wù)器的帶寬、吞吐量、數(shù)據(jù)處理能力等[1]。

民航業(yè)一直在積極建設(shè)新一代PSS，JCF(java core framework)中間件平臺是Java環(huán)境后臺交易平臺，也是新一代PSS的核心模塊之一。在JCF中間件平臺上，由于系統(tǒng)結(jié)構(gòu)和業(yè)務(wù)需求原因，部分服務(wù)的上下文環(huán)境被存儲在處理該服務(wù)請求的服務(wù)器上，不被其它服務(wù)器共享，而在處理同一個用戶后續(xù)請求過程中需要用到這些環(huán)境，此外在處理同一個用戶的后續(xù)請求時，需要用到前面請求的處理結(jié)果，所以該類用戶請求需分配到同一服務(wù)器上按時間順序進(jìn)行處理，稱之為服務(wù)的親和性。

若服務(wù)的親和性無法滿足，會出現(xiàn)用戶請求分配不合理、請求無法響應(yīng)等問題。因此，本文在研究JCF平臺負(fù)載均衡機(jī)制及多種負(fù)載均衡算法基礎(chǔ)上，提出一種親和性動態(tài)負(fù)載均衡算法，算法提取用戶標(biāo)識信息作為哈希映射鍵值，并使不同用戶請求均勻分布，保證了服務(wù)的親和性、系統(tǒng)負(fù)載均衡性能和穩(wěn)定性。

1 相關(guān)工作

負(fù)載均衡的主要功能是縮短請求響應(yīng)時間以及能夠動態(tài)適應(yīng)集群中單個服務(wù)器狀態(tài)的變化。早期的負(fù)載均衡算法較簡單考慮因素較少，隨著研究的深入，提出一些適用于不同場景的算法[2]。從民航業(yè)務(wù)服務(wù)的親和性角度，按照用戶請求分配方式，對已有算法進(jìn)行了如下分析和總結(jié)。

一類是以輪詢機(jī)制分配請求。將用戶的請求依次分配給集群系統(tǒng)中的服務(wù)節(jié)點(diǎn)，循環(huán)往復(fù)，如輪詢算法[3]。在其基礎(chǔ)上，通過為服務(wù)器分配比例因子或權(quán)值的方式，調(diào)配服務(wù)器接受請求的比例，如固定比例因子算法[4]、加權(quán)輪詢算法[5]。另一類是按照特定規(guī)則分配請求。例如，文獻(xiàn)[6]提出最小未完成交易數(shù)算法，選擇當(dāng)前未完成交易數(shù)最小的服務(wù)器分配用戶請求；文獻(xiàn)[7]提出改進(jìn)的動態(tài)告警負(fù)載均衡算法，綜合考慮請求類型、節(jié)點(diǎn)工作能力和實(shí)時負(fù)載值，再確定轉(zhuǎn)發(fā)的目標(biāo)服務(wù)器；文獻(xiàn)[8]提出基于空間填充曲線的動態(tài)負(fù)載均衡算法，使均衡器根據(jù)實(shí)時收集的各項負(fù)載指標(biāo)快速定位到最優(yōu)編碼的服務(wù)器；文獻(xiàn)[9]提出一種數(shù)據(jù)段交換算法，將內(nèi)存帶寬負(fù)載不均衡服務(wù)器上的數(shù)據(jù)段進(jìn)行相互交換，使集群的帶寬負(fù)載達(dá)到均衡。

以上多種負(fù)載均衡算法，對于來自同一用戶的連續(xù)請求，可能會被分配到不同的服務(wù)器上，不能有效滿足服務(wù)的親和性需求。結(jié)合民航業(yè)務(wù)服務(wù)的親和性以及負(fù)載均衡需求，本文設(shè)計了一種親和性動態(tài)負(fù)載均衡算法。

2 面向JCF的親和性動態(tài)負(fù)載均衡算法

為了使集群系統(tǒng)在進(jìn)行用戶請求分配過程中，滿足服務(wù)的親和性需求。面向JCF中間件平臺，提出了一種親和性動態(tài)負(fù)載均衡算法，該算法在進(jìn)行用戶請求分配過程中，優(yōu)先滿足服務(wù)的親和性需求，其次通過引入虛擬節(jié)點(diǎn)，有效保證了集群系統(tǒng)負(fù)載均衡性能，并結(jié)合實(shí)際應(yīng)用情景，設(shè)計集群規(guī)模動態(tài)調(diào)整策略。

2.1 JCF中間件

JCF中間件平臺位于服務(wù)管理平臺和新一代PSS核心組件之間，Java語言編寫的各種應(yīng)用可以部署到JCF中間件平臺上運(yùn)行。基于該平臺可以實(shí)現(xiàn)不同系統(tǒng)之間的信息交換，并最終達(dá)到資源實(shí)時調(diào)度。JCF架構(gòu)中的分布式運(yùn)行系統(tǒng)是由多個服務(wù)器組成的分布式環(huán)境，允許通過擴(kuò)展服務(wù)器個數(shù)進(jìn)行集群規(guī)模擴(kuò)展，在進(jìn)行調(diào)用分布部署的服務(wù)時提供負(fù)載均衡功能[10-12]。JCF負(fù)載均衡功能模型如圖1所示，用戶的各類服務(wù)請求通過TSI(travelsky service integration)總線接入到內(nèi)部集群系統(tǒng)，再分發(fā)到相應(yīng)的集群中。

圖1 JCF負(fù)載均衡功能模型

2.2 算法設(shè)計

親和性動態(tài)負(fù)載均衡算法基于帶有虛擬節(jié)點(diǎn)的一致性哈希算法，其基本原理如下：首先根據(jù)鍵值的比特數(shù)N(一般取N=32)可以得到一個0～232-1的哈希環(huán)；接著定義虛擬節(jié)點(diǎn)個數(shù)，一個實(shí)際服務(wù)器節(jié)點(diǎn)對應(yīng)若干個虛擬節(jié)點(diǎn)；再計算虛擬節(jié)點(diǎn)的哈希值，映射到哈希環(huán)上；然后計算用戶請求的哈希值再映射到環(huán)上，按順時針映射到距離其最近的虛擬節(jié)點(diǎn)，該虛擬節(jié)點(diǎn)所對應(yīng)的實(shí)際服務(wù)器節(jié)點(diǎn)，即為該用戶請求的實(shí)際處理節(jié)點(diǎn)。

本文在處理用戶請求時，對用戶請求的頭部攜帶的具體標(biāo)識，進(jìn)行信息提取和轉(zhuǎn)化得到用戶標(biāo)識信息，作為哈希函數(shù)的輸入。由于民航系統(tǒng)實(shí)際應(yīng)用中，同一航空公司的用戶請求的標(biāo)識是固定的，哈希環(huán)上的服務(wù)器節(jié)點(diǎn)也固定，因此，同一個用戶請求的鍵值映射到哈希環(huán)上以后，會映射到相同的服務(wù)器節(jié)點(diǎn)，以此保證服務(wù)的親和性。

本文算法引入虛擬節(jié)點(diǎn)機(jī)制，并使用運(yùn)算性能高、碰撞率低和隨機(jī)分布特征更良好的MurmurHash3算法進(jìn)行具體哈希值計算?？梢允沟霉－h(huán)上更加均勻的分布更多的虛擬節(jié)點(diǎn)，用戶請求將更加均勻的映射到每一個實(shí)際服務(wù)器節(jié)點(diǎn)上，這樣可以有效減少服務(wù)器過載和輕載問題出現(xiàn)。保證集群系統(tǒng)的負(fù)載均衡性能。

算法如圖2所示，實(shí)際服務(wù)器節(jié)點(diǎn)Server A對應(yīng)圖中Server A1和Server A2兩個虛擬節(jié)點(diǎn)，實(shí)際服務(wù)器節(jié)點(diǎn)Server B對應(yīng)圖中Server B1和Server B2兩個虛擬節(jié)點(diǎn)，req1通過哈希函數(shù)計算得到key1，并順時針映射到距離其最近的虛擬節(jié)點(diǎn)Server A2上，根據(jù)對應(yīng)關(guān)系，最終分配到Server A處理，req2、req3、req4同理，根據(jù)算法映射到各個節(jié)點(diǎn)進(jìn)行處理。

圖2 算法

2.3 算法流程

算法流程如圖3所示。

首先定義虛擬節(jié)點(diǎn)數(shù)量記為VNN，將實(shí)際服務(wù)器節(jié)點(diǎn)

圖3 算法流程

與虛擬節(jié)點(diǎn)進(jìn)行映射，即一個實(shí)際服務(wù)器節(jié)點(diǎn)對應(yīng)VNN個虛擬節(jié)點(diǎn)

(1)

其中，N為當(dāng)前集群中實(shí)際服務(wù)器節(jié)點(diǎn)總數(shù)，k為常數(shù)，W為整個集群的權(quán)重之和，wi為第i個服務(wù)器的權(quán)重。

(1)根據(jù)式(1)計算出虛擬節(jié)點(diǎn)個數(shù)，對于每個虛擬節(jié)點(diǎn)其編號Virtual_Nodeit，(1≤i≤N)，(1≤t≤VNN)，表示第i個實(shí)際服務(wù)器節(jié)點(diǎn)對應(yīng)的第t個虛擬節(jié)點(diǎn)；

(2)建立虛擬節(jié)點(diǎn)和實(shí)際服務(wù)器節(jié)點(diǎn)之間的對應(yīng)關(guān)系，一個實(shí)際服務(wù)器節(jié)點(diǎn)對應(yīng)VNN個虛擬節(jié)點(diǎn)；

(3)計算實(shí)際服務(wù)器節(jié)點(diǎn)的哈希值。在JCF中間件平臺的服務(wù)庫中，每個服務(wù)器注冊一個元數(shù)據(jù)表，根據(jù)表中服務(wù)器節(jié)點(diǎn)配置的server_name，通過MurmurHash3算法計算得到每個服務(wù)器節(jié)點(diǎn)的哈希值Node_hashi，(1≤i≤N)；

(4)計算虛擬節(jié)點(diǎn)的哈希值。對于某個虛擬節(jié)點(diǎn)，將Node_hashi加Virtual_Nodeit的值作為MurmurHash3算法輸入，計算得到每個虛擬節(jié)點(diǎn)的哈希值，記為Virtual_Node_hashit，(1≤i≤N),(1≤t≤VNN)，表示第i個實(shí)際服務(wù)器節(jié)點(diǎn)對應(yīng)的第t個虛擬節(jié)點(diǎn)的哈希值；

(5)根據(jù)Virtual_Node_hashit的值將虛擬節(jié)點(diǎn)映射到環(huán)上；

(6)用戶請求的處理。用戶根據(jù)設(shè)定規(guī)則設(shè)置請求內(nèi)容，算法解析用戶發(fā)送的http請求，從用戶請求的消息頭headers中獲取請求頭部的host值，若值的類型為字符串，首先要應(yīng)用函數(shù)將字符串類型數(shù)據(jù)轉(zhuǎn)換成整形數(shù)據(jù)。使用Fowler-NOll-Vo函數(shù)完成這個目的

keyuser=Fowler-NOLL-Vo(host)

(2)

(7)計算用戶請求的哈希值，根據(jù)keyuser通過MurmurHash3算法計算用戶請求的哈希值User_hash；

(8)處理用戶請求，將User_hash映射到環(huán)上，按順時針方向映射到距離最近的虛擬節(jié)點(diǎn)上，根據(jù)實(shí)際服務(wù)器節(jié)點(diǎn)和虛擬節(jié)點(diǎn)的對應(yīng)關(guān)系，該請求實(shí)際是映射到對應(yīng)的實(shí)際服務(wù)器節(jié)點(diǎn)上去處理；

(9)當(dāng)有新的請求發(fā)送到集群時，重復(fù)(6)～(8)步。

2.4 集群規(guī)模動態(tài)調(diào)整

在實(shí)際的使用中，集群中能夠正常提供服務(wù)的服務(wù)器的個數(shù)可能會發(fā)生變化。分為以下兩類情況：當(dāng)業(yè)務(wù)量增加，需要增加新的服務(wù)器以滿足新的業(yè)務(wù)需求，或者已宕機(jī)服務(wù)器經(jīng)過維護(hù)重新投入使用，會造成集群規(guī)模擴(kuò)展。另外，由于服務(wù)器性能下降，負(fù)載量長時間過大，運(yùn)行的程序出現(xiàn)死循環(huán)，線路或者服務(wù)器發(fā)生物理故障時，會造成集群規(guī)?？s減。

當(dāng)集群規(guī)模發(fā)生動態(tài)變化時，需要對服務(wù)請求做平滑處理，保證集群負(fù)載均衡的同時，最大程度減少受影響的用戶個數(shù)，保證絕大部分用戶服務(wù)的親和性能夠得到滿足，保證系統(tǒng)的穩(wěn)定性。本文算法針對集群規(guī)模變化，設(shè)計了如下動態(tài)調(diào)整策略：

(1)集群規(guī)模擴(kuò)展。當(dāng)需要增加服務(wù)器時，首先將服務(wù)器信息添加到服務(wù)庫中。再根據(jù)規(guī)則生成新的服務(wù)器節(jié)點(diǎn)的虛擬節(jié)點(diǎn)，并映射到環(huán)上。服務(wù)請求根據(jù)規(guī)則映射到新服務(wù)器上進(jìn)行處理。

如圖4所示，原先集群系統(tǒng)中有服務(wù)器Server A、Server B、Server C，req1映射到Server A處理，req4映射到Server B處理，req2和req3映射到Server C處理，當(dāng)集群中增加一個服務(wù)器Server D后，此時req2順時針尋找到距離其最近的服務(wù)器節(jié)點(diǎn)為Server D，則req2映射到Ser-ver D處理。其余用戶請求不受影響。

圖4 增加Server D節(jié)點(diǎn)

(2)集群規(guī)?？s減。當(dāng)需要刪除服務(wù)器時，將服務(wù)器從服務(wù)庫中刪除，并從環(huán)中刪除該服務(wù)器的所有虛擬節(jié)點(diǎn)映射，原來發(fā)送到該服務(wù)器上的用戶請求，沿順時針再繼續(xù)尋找離自己最近的服務(wù)器作為新的服務(wù)器節(jié)點(diǎn)，由新的服務(wù)器節(jié)點(diǎn)處理請求。

圖5中顯示集群中原先有4個服務(wù)器，請求映射情況為req1映射到Server A，req2映射到Server D，req3 映 射 到Server C，req4映射到Server B，此時Server B發(fā)生故障，req4按順時針方向映射到與其距離最近的Server D，其它請求映射關(guān)系不變。

圖5 刪除Server B節(jié)點(diǎn)

如圖4、圖5所示，當(dāng)增加服務(wù)器ServerD和刪除服務(wù)器ServerB后，重分布的用戶分別為req2和req4，環(huán)上其余用戶不受影響。由此表明，當(dāng)集群規(guī)模發(fā)生動態(tài)變化時，受影響的用戶僅包括，從變化服務(wù)器逆時針到距離其最近的服務(wù)器節(jié)點(diǎn)之間這一段哈希環(huán)上的用戶，其余用戶不受影響，這保證了絕大部分用戶服務(wù)的親和性，避免了大部分用戶重分布帶來的損失。當(dāng)服務(wù)器減少時，集群系統(tǒng)的負(fù)載均衡性能相對減弱，使得部分服務(wù)器負(fù)載增大。但從總體上來看，由于動態(tài)調(diào)整策略的存在，服務(wù)的親和性受影響的用戶較少，且受影響的用戶能夠得到及時有效的調(diào)整，集群系統(tǒng)的負(fù)載均衡性能受到的沖擊較小，系統(tǒng)相對穩(wěn)定。

3 系統(tǒng)仿真和算法性能分析

3.1 實(shí)驗環(huán)境與過程

實(shí)驗?zāi)MJCF中間件平臺，搭建了一套仿真實(shí)驗環(huán)境，由7臺Dell服務(wù)器組成一個小型集群系統(tǒng)。其中一臺作為服務(wù)庫，一臺作為適配器，其它作為處理用戶請求的目標(biāo)服務(wù)器，服務(wù)器的配置為：CPU型號：Intel(R) Core 2 Duo E7500;CPU內(nèi)核：2 core；RAM：6 GB，硬盤：300 G；操作系統(tǒng)：Ubuntu 14.04；運(yùn)行環(huán)境Myeclipse，jdk1.8，相關(guān)軟件：Apache JMeter。

服務(wù)庫上安裝服務(wù)注冊表，包含各臺服務(wù)器節(jié)點(diǎn)的信息，適配器上安裝Nginx反向代理服務(wù)器，為了進(jìn)行算法對比，在Nginx反向代理服務(wù)器上部署了4種算法，分別為固定比例因子算法、最小未完成交易數(shù)算法、輪詢算法和本文算法，其中固定比例因子算法和最小未完成交易數(shù)算法為JCF平臺上原有算法。

實(shí)驗中使用Apache JMeter軟件，構(gòu)造大量的http請求，在一定的時間周期內(nèi)發(fā)送到適配器上，適配器根據(jù)當(dāng)前配置的負(fù)載均衡算法，將請求轉(zhuǎn)發(fā)給后端服務(wù)器。

3.2 實(shí)驗場景與性能分析

根據(jù)本文算法的特點(diǎn)，并且結(jié)合實(shí)際的應(yīng)用需求，本文實(shí)驗場景分為4個部分：

(1)場景一：系統(tǒng)處于穩(wěn)定狀態(tài)，集群中有4個服務(wù)器處理用戶請求，使用Apache JMeter構(gòu)造大量用戶請求，在一定的時間周期內(nèi)，發(fā)送到集群系統(tǒng)，通過適配器上部署的4種不同的負(fù)載均衡算法，分配到服務(wù)器上去處理。觀察實(shí)驗結(jié)果，統(tǒng)計實(shí)驗數(shù)據(jù)，計算4種算法的親和率。

親和率計算方法如下，在一個實(shí)驗時間周期內(nèi)，一共有num個用戶訪問了集群系統(tǒng)，第i個用戶共發(fā)送NRi(1≤i≤N)個連續(xù)請求，記該用戶首次映射的服務(wù)器為目標(biāo)服務(wù)器，則第i個用戶的所有連續(xù)請求命中目標(biāo)服務(wù)器的總次數(shù)記為NOi(1≤i≤N)，則第i個用戶命中目標(biāo)服務(wù)器的命中率記為Hi

(3)

則整個集群系統(tǒng)的親和率記為A

(4)

式(4)表示，在一個實(shí)驗時間周期內(nèi)，所有訪問該集群系統(tǒng)的用戶，命中目標(biāo)服務(wù)器的命中率之和，取其平均數(shù)，即為該集群系統(tǒng)的親和率。

在配置了負(fù)載均衡算法的集群系統(tǒng)中，親和率為所有用戶的連續(xù)請求發(fā)送到其目標(biāo)服務(wù)器次數(shù)占其發(fā)送請求總次數(shù)的比率。親和率越高，即表示越多的用戶連續(xù)請求被分配到相同服務(wù)器處理，則更加滿足服務(wù)的親和性需求。通過親和率的大小，可以觀察當(dāng)前集群系統(tǒng)在滿足服務(wù)的親和性方面的表現(xiàn)。

如圖6所示為在不同用戶請求總數(shù)情況下，4種算法的親和率。系統(tǒng)的親和率隨著請求數(shù)量的增加基本處于穩(wěn)定狀態(tài)，對于固定比例因子算法、輪詢算法和最小未完成交易數(shù)算法，當(dāng)請求總數(shù)為200時，親和率分別為23.5%、26.5%和25.5%；當(dāng)請求總數(shù)為800時，親和率分別為26.6%、23.4%和22.6%；當(dāng)請求總數(shù)為2000時，親和率分別為25.3%、26.2%和26.6%；實(shí)驗結(jié)果表明，以上3種算法的親和率基本穩(wěn)定在24%、25%和25%左右。本文算法的親和率在不同請求總數(shù)情況下均為99%。對比實(shí)驗結(jié)果表明，本文算法的親和率比其它3種算法的親和率高很多，這表示本文算法能夠?qū)⒔^大部分的用戶連續(xù)請求發(fā)送到目標(biāo)服務(wù)器上去處理，有效滿足服務(wù)的親和性需求。

圖6 4種算法的親和率

(2)場景二：系統(tǒng)處于穩(wěn)定狀態(tài)，集群中有4個服務(wù)器處理用戶請求，使用Apache JMeter構(gòu)造大量用戶請求，在一定時間周期內(nèi)，發(fā)送到集群系統(tǒng)，模擬不同的請求并發(fā)數(shù)，并發(fā)數(shù)由少至多。統(tǒng)計請求總響應(yīng)時間和系統(tǒng)吞吐量，請求總響應(yīng)時間為系統(tǒng)處理請求并響應(yīng)的總時間，系統(tǒng)吞吐量表示每秒完成的請求數(shù)。

如圖7所示，當(dāng)請求并發(fā)數(shù)遞增時，固定比例因子算法的請求響應(yīng)時間從0.09 s增加到0.26 s；輪詢算法的請求響應(yīng)時間從0.076 s增加到0.275 s；最小未完成交易數(shù)算法的請求響應(yīng)時間從0.02 s增加到0.2 s；本文算法的請求相應(yīng)時間從0.02 s增加到0.18 s，4種算法的請求總響應(yīng)時間，隨著請求并發(fā)數(shù)的增加不斷增加，其中本文算法請求響應(yīng)時間相對較短。

圖7 4種算法的請求總響應(yīng)時間

這是由于固定比例因子算法、輪詢算法和最小未完成交易數(shù)算法，這3種算法的請求分配機(jī)制均不能保證連續(xù)請求被分配到同一服務(wù)器。由于此時未滿足服務(wù)的親和性，會導(dǎo)致該請求無法及時響應(yīng)或者無法響應(yīng)，增加系統(tǒng)的請求總響應(yīng)時間。

本文算法在處理同一用戶的連續(xù)請求時，由于標(biāo)識固定，會將這些連續(xù)請求發(fā)送到同一服務(wù)器的服務(wù)隊列中，按照時間順序處理，避免由于服務(wù)所需資源與服務(wù)器綁定，而導(dǎo)致的請求無法響應(yīng)問題，同時減少由于后續(xù)請求需要前面請求處理結(jié)果的等待時間，因此使得服務(wù)的親和性得以保證，負(fù)載均衡情況下請求響應(yīng)時間相對較短。

如圖8所示，當(dāng)請求并發(fā)數(shù)為60 個/s時，固定比例因子算法、輪詢算法、最小未完成交易數(shù)算法和本文算法的吞吐量分別為：36.2個/s、37.5個/s、38.3個/s、38.4個/s；當(dāng)請求并發(fā)數(shù)為500個/s時，4種算法的吞吐量分別為：119.0個/s、101.6個/s、117.6個/s、118.1個/s。4種算法的系統(tǒng)吞吐量隨著請求并發(fā)數(shù)量的增多呈上升趨勢，本文算法的系統(tǒng)吞吐量和其它算法的系統(tǒng)吞吐量接近，并發(fā)量高時略低于其它算法。

圖8 4種算法的吞吐量

這是由于當(dāng)多個用戶在一定時間周期內(nèi)，發(fā)送來多個連續(xù)請求，并且這些用戶請求映射到相同的服務(wù)器上去處理，該服務(wù)器的處理壓力會增大，極端情況時服務(wù)器會由于過載而宕機(jī)。此時，服務(wù)器處理能力會明顯降低，集群系統(tǒng)吞吐量相應(yīng)的會降低。

(3)場景三：集群系統(tǒng)規(guī)模擴(kuò)展，新增加一個服務(wù)器，先到服務(wù)注冊庫中注冊，此時服務(wù)器總數(shù)增加至5臺，適配器上部署本文算法，用戶請求的映射根據(jù)2.4節(jié)介紹的動態(tài)調(diào)整策略變化。觀察同一類請求的分布情況，分析請求在系統(tǒng)規(guī)模擴(kuò)展情況下，多少用戶請求受到了影響，若在一個實(shí)驗周期內(nèi)，由于服務(wù)器增加，導(dǎo)致某一用戶請求需重映射到新的目標(biāo)服務(wù)器，則記變化一次，統(tǒng)計總的變化次數(shù)CT，記該周期內(nèi)所有用戶發(fā)送請求的總數(shù)為num_req，記系統(tǒng)的變化率為CR，則

(5)

(4)場景四：集群系統(tǒng)規(guī)?？s減，模擬集群系統(tǒng)中有一臺服務(wù)器出現(xiàn)故障，從服務(wù)器注冊庫中刪除了一個服務(wù)器，服務(wù)器總數(shù)減少至3臺，適配器上部署本文算法，用戶請求的映射根據(jù)2.4節(jié)介紹的動態(tài)調(diào)整策略變化。觀察同一類請求分布情況，統(tǒng)計系統(tǒng)變化率。

場景三和場景四，分別模擬了給集群增加一個服務(wù)器和減少一個服務(wù)器的情況，并統(tǒng)計集群的變化率，實(shí)驗結(jié)果見表1。

表1 變化率統(tǒng)計

兩種狀態(tài)下本文算法的變化率分別為21%和34%，即表明變化節(jié)點(diǎn)沿逆時針到距離其最近的服務(wù)器節(jié)點(diǎn)之間這一段哈希環(huán)上的用戶請求數(shù)占總請求數(shù)的21%和34%。這說明分別有21%和34%的用戶的連續(xù)請求受到影響，并根據(jù)動態(tài)調(diào)整策略重分布到新的服務(wù)器處理。實(shí)驗結(jié)果表明，本文算法保證了絕大多數(shù)用戶的請求處理不受到集群系統(tǒng)規(guī)模變化的影響，避免了所有用戶重分布的情況發(fā)生，保證了絕大多數(shù)用戶服務(wù)的親和性。同時受影響的一部分用戶請求，能根據(jù)動態(tài)調(diào)整策略重映射到新的服務(wù)器上處理，由于算法設(shè)置的虛擬節(jié)點(diǎn)在哈希環(huán)上分布較均勻，部分請求重映射不會造成某一服務(wù)器嚴(yán)重過載現(xiàn)象，對集群系統(tǒng)的負(fù)載均衡沖擊較小，保證了系統(tǒng)的穩(wěn)定性。

不同場景下的實(shí)驗結(jié)果表明，本文提出的親和性動態(tài)負(fù)載均衡算法，優(yōu)先保證服務(wù)的親和性，雖犧牲了一部分負(fù)載均衡性能，使得負(fù)載均衡效果沒有優(yōu)于其它算法，但是集群系統(tǒng)的負(fù)載均衡仍得以保證。根據(jù)實(shí)際生產(chǎn)需求，而設(shè)計的集群規(guī)模變化實(shí)驗結(jié)果表明，系統(tǒng)的親和性和穩(wěn)定性均能夠得到保證。

4 結(jié)束語

為了解決民航業(yè)大規(guī)模分布式集群系統(tǒng)在進(jìn)行用戶請求負(fù)載分配過程中，出現(xiàn)服務(wù)的親和性和負(fù)載均衡問題，分析了JCF中間件平臺上原有的負(fù)載均衡算法以及其它常見負(fù)載均衡算法的特點(diǎn)，基于帶有虛擬節(jié)點(diǎn)的一致性哈希算法，提出一種親和性動態(tài)負(fù)載均衡算法，通過設(shè)計對比實(shí)驗，驗證了該算法能夠使得用戶請求得到合理的分配，滿足服務(wù)的親和性需求，同時具有負(fù)載均衡功能，并保證集群系統(tǒng)的穩(wěn)定性和可伸縮性。

但是，該算法還有許多不足，如何在此基礎(chǔ)上，進(jìn)一步提升算法的負(fù)載均衡效果，將是下一步重點(diǎn)研究內(nèi)容。