Redis集群可靠性的研究與優(yōu)化

李 燚,顧乃杰,黃增士,任開新

(1.中國科學(xué)技術(shù)大學(xué) a.計算機科學(xué)與技術(shù)學(xué)院; b.先進技術(shù)研究院,合肥 230027; 2.安徽省計算與通信軟件重點實驗室,合肥 230027)

0 概述

Redis[1]是一種基于鍵值對存儲的內(nèi)存數(shù)據(jù)庫,能夠提供高速的數(shù)據(jù)庫訪問,并實現(xiàn)了復(fù)制備份和數(shù)據(jù)持久化的功能。相比于其他內(nèi)存數(shù)據(jù)庫,例如Memcached[2],Redis支持多種數(shù)據(jù)類型。由于具有高性能、多數(shù)據(jù)類型支持、數(shù)據(jù)安全性等優(yōu)勢,Redis近年來發(fā)展迅速,并得到了廣泛應(yīng)用。已經(jīng)有很多互聯(lián)網(wǎng)企業(yè)使用Redis,例如新浪、GitHub、Pinterest[3]等。Redis應(yīng)用領(lǐng)域也很廣泛,例如做動態(tài)緩存[4]、可視化數(shù)據(jù)庫[5]、云數(shù)據(jù)庫[6]等。

Redis集群能夠彌補單線程的Redis節(jié)點性能上的不足,還可以提供數(shù)據(jù)冗余、結(jié)構(gòu)冗余的特性。在Redis集群中,數(shù)據(jù)分布存儲在各個節(jié)點,單點故障問題不可避免。發(fā)生故障后集群的容錯機制決定了集群恢復(fù)的效率,也就影響到集群對外服務(wù)的可靠性。Redis集群現(xiàn)有的容錯機制效率比較低,在實際使用過程中,當(dāng)主要節(jié)點發(fā)生故障時,恢復(fù)過程緩慢,集群可靠性還有待提升。提升集群可靠性,一方面可以推動Redis的發(fā)展,另一方面可以降低集群故障給用戶帶來的損失。

影響集群可靠性的因素主要有集群架構(gòu)、網(wǎng)絡(luò)通信質(zhì)量、軟硬件可靠性、集群容錯機制、數(shù)據(jù)恢復(fù)機制等。目前對于分布式集群的架構(gòu)和可靠性的研究非常多。文獻[7]提供一種在TCP連接層對集群可靠性進行優(yōu)化的方法。通過使用冗余的TCP棧實現(xiàn)套接字遷移,來保證服務(wù)端節(jié)點的TCP連接的可靠性。這種方法只是在網(wǎng)絡(luò)連接層降低了發(fā)生單點故障的概率,如果是因為其他原因?qū)е鹿?jié)點故障,仍然需要通過容錯機制進行集群恢復(fù)。文獻[8]研究了數(shù)據(jù)冗余和硬件冗余對集群可靠性的影響,并提出一種結(jié)合了節(jié)點互備份和冗余節(jié)點備份的恢復(fù)機制,其中冗余節(jié)點備份類似于Redis的主從模式。文獻[9]介紹一種新的復(fù)制備份方案NRDT,該方案通過在鄰接點間進行數(shù)據(jù)備份來提高集群可靠性,即一個節(jié)點的服務(wù)數(shù)據(jù)復(fù)制備份到鄰居節(jié)點上。但是發(fā)生多節(jié)點故障時,這種冗余方法容易導(dǎo)致個別節(jié)點的負載較重,影響集群的性能。文獻[10]實現(xiàn)了針對UCWW系統(tǒng)的Redis集群架構(gòu)。該架構(gòu)使用ZooKeeper對Redis節(jié)點進行管理,需要的ZooKeeper節(jié)點個數(shù)與Redis節(jié)點個數(shù)相關(guān)。該集群方案需要額外的監(jiān)測節(jié)點,而且架構(gòu)的設(shè)計針對于UCWW系統(tǒng),不具有通用性。

相比于現(xiàn)有的研究方案,本文對Redis集群可靠性的研究和優(yōu)化集中在通信層。通過對Redis集群的容錯機制進行階段劃分,針對各個階段進行分析?；趯Ω麟A段通信過程的研究,提出一種集群節(jié)點間的通信模型,并在此模型基礎(chǔ)上,實現(xiàn)一種通信負載均衡的優(yōu)化方法。

1 Redis研究背景

1.1 Redis集群結(jié)構(gòu)

Redis節(jié)點可以主從方式構(gòu)成集群,從節(jié)點對主節(jié)點進行復(fù)制備份,相當(dāng)于一種冗余結(jié)構(gòu)[11]。集群節(jié)點兩兩之間建立了P2P的TCP連接,以發(fā)送和接收消息的方式進行通信,構(gòu)成全網(wǎng)狀的網(wǎng)絡(luò)拓撲結(jié)構(gòu)[1]。圖1是6個節(jié)點組成的Redis集群,最小的Redis集群只有3個主節(jié)點。作為一種分布式的結(jié)

構(gòu),Redis集群中實現(xiàn)了一種基于Gossip協(xié)議的一致性通信算法,來完成消息的消息傳播、數(shù)據(jù)交換和狀態(tài)同步[12]。使用Gossip協(xié)議既能有效保證集群的一致性,又避免了通信負載指數(shù)級的增長。

圖1 6個節(jié)點組成的一主一從Redis集群

Gossip協(xié)議是在大規(guī)模并行環(huán)境內(nèi)部建立穩(wěn)定、可靠的通信機制的一種有效方案,廣泛地應(yīng)用到P2P網(wǎng)絡(luò)中。在Gossip協(xié)議中,節(jié)點以一種類似疫情傳播的方式進行數(shù)據(jù)交換、消息通信[13]。Gossip協(xié)議是一種最終一致性算法,即弱一致性算法,不能保證在某個時間點整個集群的所有節(jié)點達到一致的狀態(tài),但可以保證隨著時間的推移,集群最終會達到一致性的狀態(tài)。

1.2 容錯機制

在集群運行過程中,如果存在主節(jié)點因為軟硬件原因離線,需要通過容錯機制來確定離線的主節(jié)點,并進入故障轉(zhuǎn)移過程來指派新的主節(jié)點。如圖2所示,下線檢測和故障轉(zhuǎn)移是集群容錯機制的2個主要階段。如果按照節(jié)點狀態(tài)和集群狀態(tài)進行劃分,又可分為PFAIL階段、FAIL階段和RECOVER階段。PFAIL和FAIL來源于節(jié)點的狀態(tài),分別對應(yīng)疑似下線和下線。

圖2 容錯機制下的宕機恢復(fù)過程

1.2.1 下線檢測

集群中的每個節(jié)點和其他節(jié)點進行周期性的間隔通信。這種周期性通信消息,即心跳消息在集群間傳遞節(jié)點狀態(tài)以及可用性的信息[14]。周期性通信的方法記為F,執(zhí)行周期記為HZ。Redis集群中心跳消息主要包括PING、PONG,一次PING、PONG通信簡化過程的等待超時時間記為T。

發(fā)送方節(jié)點通過以下2種方式選取需要發(fā)送PING消息的節(jié)點:

1)每隔1 s隨機性地選取一個節(jié)點,向其發(fā)送心跳消息。

2)每次執(zhí)行F,一次性選出上次通信距現(xiàn)在超過T/2的節(jié)點,向這些節(jié)點發(fā)送心跳消息,從而保證每隔T/2的時間都和其他節(jié)點通信一次。

每條心跳消息(PING、PONG)包含發(fā)送方節(jié)點的狀態(tài)信息和GossipSection。GossipSection包含若干條Gossip數(shù)據(jù),每條Gossip數(shù)據(jù)對應(yīng)一個Redis節(jié)點,包含該節(jié)點的狀態(tài)信息,即發(fā)送方節(jié)點將集群中若干節(jié)點的信息隨心跳消息發(fā)送給接收方。GossipSection中節(jié)點的選取具有隨機性。如圖3所示,接收方收到PING、PONG消息后,首先解析消息提取發(fā)送方的信息進行更新,然后解析GossipSection中的每條數(shù)據(jù),更新到本地。

圖3 節(jié)點間PING、PONG通信過程

如圖3發(fā)送PING消息后,在超時時間T內(nèi)未收到PONG回復(fù),就將對應(yīng)節(jié)點標(biāo)記為PFAIL狀態(tài),對應(yīng)圖2的PFAIL階段。節(jié)點間不斷進行心跳消息的通信,隨著時間的推移,在節(jié)點間對于PFAIL狀態(tài)節(jié)點的判斷逐漸形成一致性的認識,在此過程中如果超過半數(shù)主節(jié)點都標(biāo)記某個節(jié)點為PFAIL,就確定該節(jié)點下線,對應(yīng)圖2的FAIL階段(GossipSection中解析的PFAIL標(biāo)記有2T的有效時間,超時后不能用來判斷FAIL狀態(tài))。所以FAIL狀態(tài)是集群中多數(shù)節(jié)點協(xié)同得到的一致性結(jié)果。通過PFAIL階段和FAIL階段就完成了下線檢測的過程。

1.2.2 故障轉(zhuǎn)移過程

故障轉(zhuǎn)移是在主節(jié)點故障后進行主從切換的過程[15]。在通過下線檢測過程確認主節(jié)點宕機后,其從節(jié)點就會通過Raft選舉算法獲得多數(shù)主節(jié)點的認可,當(dāng)選為新的主節(jié)點。首先從節(jié)點在集群中發(fā)起選舉進入故障轉(zhuǎn)移的過程。選舉信息在集群中廣播,收到選舉信息的主節(jié)點給該從節(jié)點投票,當(dāng)從節(jié)點得到的票數(shù)超過主節(jié)點總數(shù)一半時,可當(dāng)選為新的主節(jié)點并廣播當(dāng)選信息,集群恢復(fù)上線。

1.3 技術(shù)優(yōu)勢

根據(jù)對集群結(jié)構(gòu)和集群容錯機制的分析,Redis集群有以下3點優(yōu)勢:

1)多冗余功能:Redis的主從集群結(jié)構(gòu),給自身提供了硬件和結(jié)構(gòu)冗余的功能,從節(jié)點對主節(jié)點的復(fù)制備份的功能提供了數(shù)據(jù)冗余的功能。

2)自動容災(zāi):集群發(fā)生故障時,在集群內(nèi)部能夠自動完成下線檢測、故障轉(zhuǎn)移的過程,不需要額外的監(jiān)控節(jié)點協(xié)助完成。

3)一致性保證:在容錯機制中使用Gossip通信協(xié)議維持集群狀態(tài)的一致性,保證下線檢測的準確性。在故障轉(zhuǎn)移過程中,使用Raft一致性算法,保證主從切換的唯一。

2 優(yōu)化方案分析與設(shè)計

2.1 優(yōu)化方案分析

通過對Redis集群容錯機制中節(jié)點通信過程的分析,考慮在集群中對于PFail狀態(tài)進行疫情傳播的通信模型,可結(jié)合疫情傳播的易受感染(Susceptible Infective,SI)模式進行分析。假設(shè)集群的主節(jié)點個數(shù)為N,將集群中的節(jié)點分為2種:1)感知態(tài),感知態(tài)節(jié)點已經(jīng)知道PFail狀態(tài)節(jié)點,下一步需要進行傳播;2)未知態(tài),未知態(tài)節(jié)點沒有感知PFail狀態(tài)節(jié)點。

初始時只有一個感知態(tài)節(jié)點,每次隨機選取一個節(jié)點進行狀態(tài)傳播,記為一輪。則在一輪過后,增加一個感知態(tài)節(jié)點的概率為1-1/N。在下一輪,所有感知節(jié)點都分別再進行一輪狀態(tài)傳播。傳播過程記為{I(k),k≥0},I(k)表示k輪傳播后感知態(tài)節(jié)點的個數(shù),其中I(0)=1。

(1)

使用二項式定理和組合數(shù)公式簡化后得到下式:

(2)

解二次遞推公式得到下式:

(3)

式(3)給出了在k輪消息傳播后感知態(tài)節(jié)點的個數(shù)。當(dāng)感知態(tài)個數(shù)達到N時,集群達到一致狀態(tài);當(dāng)感知態(tài)個數(shù)達到N/2+1時,能夠完成下線檢測。對于后者,根據(jù)式(3)得到PFail狀態(tài)傳播輪數(shù)k:

(4)

在上述通信模型中,k是狀態(tài)傳播經(jīng)過的輪數(shù),每次傳播一個節(jié)點。對于每次狀態(tài)傳播發(fā)送多條消息的情況,按照上述過程難以得到簡化結(jié)果?？梢院喕紤]:將發(fā)送的每條消息看作狀態(tài)傳播的一輪。對Redis集群,假設(shè)消息發(fā)送頻率為k′,則感知態(tài)個數(shù)達到N/2+1的耗時為t=k/k′。

根據(jù)第1節(jié)對集群通信過程的介紹,假設(shè)集群通信消息發(fā)送頻率為m,由于心跳消息的GossipSection包含PFail狀態(tài)有一定隨機性,假設(shè)包含PFail狀態(tài)的概率為p(0

(5)

所以按照一條心跳消息作為一輪狀態(tài)傳播的過程考慮,PFail狀態(tài)傳播N/2+1個節(jié)點時,集群能夠完成下線檢測,耗時t和mp成反比關(guān)系。而結(jié)合第1節(jié)對通信過程的分析,存在以下問題:

1)節(jié)點發(fā)送心跳消息的頻率m較低。由目標(biāo)節(jié)點的選取和發(fā)送消息的時機分析,理論上每隔T/2的時間,會有一次心跳消息集中發(fā)送的現(xiàn)象發(fā)生,產(chǎn)生消息發(fā)送的峰值點,非峰值點的消息發(fā)送頻率比峰值點要低很多,導(dǎo)致消息通信在時間上的負載不均衡。這種不均衡也通過測試結(jié)果得到了驗證。

2) GossipSection節(jié)點選取的隨機性導(dǎo)致p較小。在發(fā)送的心跳消息中,添加到GossipSection的節(jié)點的選取有隨機性,不能保證PFAIL狀態(tài)的節(jié)點添加到GossipSection,降低了有效PFail狀態(tài)的心跳消息的發(fā)送頻率。

所以根據(jù)以上分析,可以從兩方面對Redis集群容錯機制的FAIL階段進行優(yōu)化:1)通信負載均衡,既不增加通信負荷,又能提高非峰值點的消息發(fā)送頻率m;2)GossipSection節(jié)點的選取,優(yōu)先添加PFAIL狀態(tài)的節(jié)點,增加心跳消息中有效消息占的比例p。

2.2 通信負載均衡

根據(jù)第1節(jié)的介紹,原始的心跳消息發(fā)送過程可以分為2個部分:周期定量發(fā)送,T/2時刻批量補發(fā)送,導(dǎo)致心跳消息的發(fā)送在時間上分布不均。通過使用通信負載均衡的方法可以消除峰值,增加非峰值點的發(fā)送頻率。

簡化消息發(fā)送過程,實現(xiàn)負載均衡,要考慮以下3個問題:

1)節(jié)點心跳消息的通信量在時間上均勻分布,保證通信負載均衡;

2)既要保證集群節(jié)點之間的通信量:在T/2時間內(nèi)單個節(jié)點和其他節(jié)點至少通信一次,又不能增加通信負載,對集群性能產(chǎn)生太大影響;

3)避免和某些節(jié)點產(chǎn)生較長的通信空白,所以需要按照一定的優(yōu)先級調(diào)度通信節(jié)點。

假設(shè)在T/2時間內(nèi)與其他所有節(jié)點通信次數(shù)為S,為了滿足負載均衡的目的,可以用減量均分的方法動態(tài)計算每次執(zhí)行周期函數(shù)F時的消息發(fā)送量。設(shè)F周期為HZ,則T/2時間內(nèi)執(zhí)行次數(shù)為K;設(shè)第i次執(zhí)行F發(fā)送消息量記為pi(p0=0),在T/2時間內(nèi),每次執(zhí)行F,需要根據(jù)剩余消息量重新計算pi。

(6)

(7)

為了避免同其他節(jié)點產(chǎn)生通信空白,使用優(yōu)先級隊列保存所有節(jié)點,優(yōu)先級設(shè)置為與該節(jié)點上次通信距離現(xiàn)在的時間,時間越長優(yōu)先級越高,可以保證優(yōu)先選取的目標(biāo)節(jié)點是最久沒有通信過的。在集群建立時初始化2個優(yōu)先級隊列Q1和Q2,Q1是待發(fā)送消息的目標(biāo)節(jié)點,Q2是已發(fā)送消息的節(jié)點。每次從Q1隊列頭選取目標(biāo)節(jié)點,發(fā)送消息后放入Q2隊列尾。每隔T/2,Q1和Q2完成一次交換。在集群規(guī)模發(fā)生變化時,也很容易通過更新Q1更新集群通信量。

負載均衡的消息發(fā)送過程如下所示:

1)集群建立時,初始化隊列Q1為空,Q2包含所有節(jié)點,初始化計數(shù)器i=1;

2)如果Q1為空且i=1,交換Q1和Q2;

3)結(jié)合式(6)計算消息發(fā)送量pi=Q1.length/(K-i+1);

4)從Q1中彈出pi個節(jié)點,發(fā)送心跳消息,并將節(jié)點壓入Q2,i=(i+1)%K;

5)周期函數(shù)下一輪從2)繼續(xù)執(zhí)行。

通信過程具體實現(xiàn)如下:

1.//集群啟動時初始操作

2.i←0;

3.K←(T*HZ)/2 000;

4.InitPriorityQueue(Q1,null);

5.InitPriorityQueue(Q2,cluster_nodes);

6.…

7.//以下是循環(huán)過程

8.if Q1.empty() & i == 1 then

9. Swap(Q1,Q2);

10.end

11.size←Q1.length;//剩余節(jié)點數(shù)

12.pi←size/(K-i+1);

13.i←i % K+1;

14.for j=1 to pi do

15. node←Q1.pop();

16. if node.ping_sent = =0 then

17. sendPingToNode(node);

18. end;

19. Q2.push(node);

20.end

第11行～第12行結(jié)合式(3)根據(jù)F執(zhí)行次數(shù)和Q1的長度更新需要發(fā)送的消息個數(shù)pn,保證在T/2時間內(nèi)和所有節(jié)點通信一次。第14行～第20行完成節(jié)點選取和發(fā)送消息的過程,第16行篩選掉已經(jīng)發(fā)送的心跳消息,但沒有收到回復(fù)也沒有超時的節(jié)點,防止消息堆積。

2.3 GossipSection節(jié)點的選取

原始的心跳消息GossipSection包含節(jié)點的選取具有隨機性。針對這個問題,改進Gossip單元選取過程,將處于PFAIL狀態(tài)的節(jié)點優(yōu)先添加到Gossip單元中,根據(jù)式(2),此舉的目的是為了增加p的值。節(jié)點選取過程較簡單,主要需要考慮以下問題:

1)消除隨機性,絕對優(yōu)先級選取PFail狀態(tài)的節(jié)點;

2)確定GossipSection的大小,使盡快完成節(jié)點狀態(tài)交換。

在集群中添加額外數(shù)據(jù)結(jié)構(gòu)PFailNodes,使用自帶的字典結(jié)構(gòu)實現(xiàn),保存所有PFAIL狀態(tài)的節(jié)點。在更新節(jié)點狀態(tài)時,同步地更新PFailNodes。在添加PFail節(jié)點時,可以直接從PFailNodes中選取。

不考慮優(yōu)先添加節(jié)點的情況,設(shè)添加到GossipSection的節(jié)點個數(shù)為n。對節(jié)點的PFAIL標(biāo)記的有限期限為2T,在2T的時間內(nèi),能和單個節(jié)點完成4次PING/PONG通信,共8條消息。設(shè)集群大小為N,如果要在2T的有效時間內(nèi)完成對所有節(jié)點的狀態(tài)信息交換,就需要在每條信息里添加N/8個節(jié)點的GossipSection數(shù)據(jù),即n=N/8。

相對于消息通信量,GossipSection的增加對通信負載的影響小得多,所以在優(yōu)先添加PFail節(jié)點的情況下,可以適量地放寬n的值。設(shè)GossipSection的大小為n+PFailNodes.size(),后者是PFail狀態(tài)節(jié)點的個數(shù)。每次構(gòu)造心跳消息選取GossipSection節(jié)點的過程如下:

1)添加PfailNodes中所有節(jié)點到GossipSection;這樣能夠保證發(fā)送的每條心跳消息都包含PFail節(jié)點,即p=1,達到最大值;

2)在剩余節(jié)點中,隨機選取n=N/8和節(jié)點添加到GossipSection,并保證GossipSection節(jié)點互異。

具體實現(xiàn)為:n是添加到GossipSection的非PFAIL狀態(tài)的節(jié)點個數(shù),gossipcount是已經(jīng)添加的節(jié)點個數(shù),msg是構(gòu)造的消息。先遍歷PFailNode,將其中節(jié)點添加到GossipSection。然后隨機選取n個節(jié)點添加到GossipSection,并保證GossipSection中節(jié)點的不重復(fù)。

1.n←Max(N/8,3);

2.gossipcount←0;

3.for i=1 to PFailNodes.size() do

4. node←PFailNodes[i];

5. AddNodeToGossipSection(msg,node);

6. gossipcount←gossipcount+1;

7.end

8.for i=1 to n do

9. node←getRandomNode();

10. …

11.for j=1 to gossipcount do

12. if node = msg→gossipsection[j] then

13. continue;

14. end

15. end

16. AddNodeToGossipSection(node,msg);

17. gossipcount = gossipcount+1;

18.end

3 測試結(jié)果

測試的Redis版本分別是Redis-3.0.7穩(wěn)定發(fā)布版本以及在Redis-3.0.7上的優(yōu)化版本,本文中原版、優(yōu)化前版本都是指Redis-3.0.7。測試用到2臺物理主機,每臺有48核、256 GB內(nèi)存,CPU型號為Intel(R) Xeon(R) CPU E5-2690 v3@2.60 GHz;測試集群規(guī)模為30個主節(jié)點、一主兩從,共90個節(jié)點。為了對優(yōu)化效果進行驗證,以及說明優(yōu)化后產(chǎn)生很小的通信負載,而且這部分通信負載的產(chǎn)生對集群的性能不會產(chǎn)生明顯影響,分別從以下3點進行測試:1)集群宕機恢復(fù)過程的耗時對比;2)優(yōu)化前后單個節(jié)點對其他節(jié)點的通信量對比;3)優(yōu)化前后集群的吞吐量和操作延時的對比。

3.1 宕機恢復(fù)過程對比

集群恢復(fù)時間的測試能夠體現(xiàn)出集群對于故障宕機的處理效率,能夠體現(xiàn)集群處理故障的可靠性。本文將集群宕機恢復(fù)過程分為3個階段進行測試,即PFAIL階段、FAIL階段、RECOVER階段,各階段耗時依次記為t1、t2、t3。階段劃分參考圖2。

宕機恢復(fù)總時間=t1+t2+t3。t1≈T(默認15 000 ms),t3和節(jié)點選取過程有關(guān)。因為優(yōu)化方案主要針對于FAIL階段,所以為了測試優(yōu)化后宕機恢復(fù)過程效率的提升,在測試集群中人為宕機1個～14個主節(jié)點(超過主節(jié)點總數(shù)一半的話,不能恢復(fù)),分別對優(yōu)化前后的FAIL階段耗時t2和恢復(fù)總時間進行對比分析。

測試結(jié)果對比如圖4和圖5所示。由圖4可以看出,優(yōu)化后的Redis集群在FAIL階段的效率有很大提升;相對于原版的Redis集群,FAIL階段宕機判斷的效率提升了80%以上,優(yōu)化效果很明顯。圖5顯示了FAIL階段的優(yōu)化對于宕機恢復(fù)整體過程的影響,優(yōu)化后的集群在宕機恢復(fù)的效率即恢復(fù)總時間上,相比于原版有28%以上的提升。

圖4 FAIL階段耗時對比

圖5 宕機恢復(fù)總時間對比

3.2 消息通信分布均衡性

本文提出并實現(xiàn)的優(yōu)化方案對節(jié)點發(fā)送心跳消息的過程進行優(yōu)化,使得消息發(fā)送的過程在時間上均勻分布,達到負載均衡的目的,避免消息發(fā)送過程中出現(xiàn)周期性的峰值。通過提取消息發(fā)送日志,對優(yōu)化前后單個節(jié)點在60 s內(nèi)的消息發(fā)送過程進行統(tǒng)計,結(jié)果如圖6所示。由圖6對比可以看出,優(yōu)化后的集群節(jié)點在發(fā)送消息時在時間上的分布均勻,沒有出現(xiàn)明顯的峰值。

圖6 消息發(fā)送時間分布對比

通過對圖6中60 s內(nèi)的消息發(fā)送總量進行統(tǒng)計發(fā)現(xiàn),優(yōu)化前發(fā)送消息總量為717條,優(yōu)化后為723條,通信負載增加幅度在0.84%左右,通信負載的增加可以忽略。

3.3 對集群性能的影響

使用redis-benchmark對Redis集群的常用操作命令進行測試,測試指標(biāo)包括集群執(zhí)行每條操作的時延以及集群的吞吐量(QPS:每秒鐘處理的請求數(shù))。分別對每種操作在優(yōu)化前后的時延(ta和tb)、吞吐量(qa和qb)進行對比,計算時延、吞吐量的變化Δt和Δq,結(jié)果如表1、表2所示。其中,Δt=(ta-tb)/ta,Δq=(qb-qa)/qa。

表1 優(yōu)化前后時延對比

表2 優(yōu)化前后吞吐量對比

根據(jù)表1和表2的數(shù)據(jù)可以看出,通過redis-benchmark測試得出的時延和吞吐量,優(yōu)化前后對比性能有升有降,變化幅度大小不一。其實原始版本Redis集群的吞吐量和時延在進行測試時,也會在一定范圍內(nèi)波動。在相同的測試條件下,表1和表2體現(xiàn)出優(yōu)化后的Redis集群的性能波動,在可接受的誤差范圍之內(nèi),所以總體來說對集群的吞吐量、時延的影響可以忽略不計。

4 結(jié)束語

本文通過對Redis集群通信層進行研究,對集群間基于心跳消息的通信過程進行優(yōu)化,提出了一種適用于大規(guī)模集群的消息傳輸模型。通過通信負載均衡的方法以及對消息的Gossip字段的優(yōu)先級選取,在不帶來額外的通信負載、不影響集群性能的情況下,提升了集群宕機恢復(fù)過程的效率,使得Redis集群宕機恢復(fù)過程的效率有了28%以上的提升,并增強了Redis集群的可靠性。

Redis集群只能在宕機主節(jié)點數(shù)少于主節(jié)點總數(shù)一半時才能從故障中恢復(fù),這是由Redis本身實現(xiàn)的選舉算法決定的。下一步工作是通過對選舉算法進行分析改進,使得多數(shù)主節(jié)點故障宕機時集群也能夠成功恢復(fù),提升Redis集群對宕機節(jié)點數(shù)目的容忍度。

[1] Redislabs.Redis cluster specification[EB/OL].[2017-03-13].http://redis.io/topics/cluster-spec/.2016 April.

[2] FITZPATRICK B.Distributed caching with memcached[EB/OL].[2017-03-13].http://www.linuxjournal.com/article/7451.

[3] SHARMA V,CARROLL J,KHUNE A.Scaling deep social feeds at pinterest[C]//Proceedings of IEEE International Conference on Social Computing.Washington D.C.,USA:IEEE Press,2013:777-783.

[4] CIDON A,EISENMAN A,ALIZADEH M,et al.Dynacache: dynamic cloud caching[C]//Proceedings of the 7th USENIX Conference on Hot Topics in Cloud Computing.New York,USA:ACM Press,2015:19.

[5] 焦 健,李 巖.基于Redis的SVG空間信息可視化數(shù)據(jù)庫[J].小型微型計算機系統(tǒng),2015,36(6):1193-1198.

[6] 阿里云.云數(shù)據(jù)庫Redis版[EB/OL].[2017-03-13].https://help.aliyun.com/document_detail/26342.html.

[7] SHAO Zhiyuan,JIN Hai,CHEN Bin,et al.HARTs:high availability cluster architecture with redundant TCP stacks[C]//Proceedings of IEEE International Conference on Performance,Computing,and Communications.Washington D.C.,USA:IEEE Press,2003:253-260.

[8] BASSEK C K,PIERRE S,QUINTERO A.Redundancy schemes for high availability computer clusters[J].Journal of Computer Science,2006,2(1):33-47.

[9] DERIS M M,RABIEI M,NORAZIAH A,et al.High service reliability for cluster server systems[C]//Proceedings of IEEE International Conference on Cluster Computing.Washington D.C.,USA: IEEE Press,2003:281-288.

[10] JI Zhanlin,GANCHEV I,O'DROMA M,et al.A distributed Redis framework for use in the UCWW[C]//Proceedings of International Conference on Cyber-enabled Distributed Computing and Knowledge Discovery.Washington D.C.,USA:IEEE Press,2014:241-244.

[11] 黃健宏.Redis設(shè)計與實現(xiàn)[M].北京:機械工業(yè)出版社,2015.

[12] KERMARREC A M,VAN STEEN M.Gossiping in distributed systems[J].Acm Sigops Operating Systems Review,2007,41(5):2-7.

[13] 劉德輝,尹 剛,王懷民,等.分布環(huán)境下的Gossip算法綜述[J].計算機科學(xué),2010,37(11):24-28.

[14] ROBERTSON A.Linux-HA heartbeat system design[C] //Proceedings of the 4th Annual Linux Showcase & Conference.New York,USA:ACM Press,2000:20.

[15] 張小芳,胡正國,鄭繼川,等.高可用性集群技術(shù)的研究和應(yīng)用[J].計算機工程,2003,29(4):26-27.