本發(fā)明涉及數(shù)據(jù)緩存技術(shù)領(lǐng)域，尤其涉及一種zedis分布式緩存及服務(wù)器集群監(jiān)控方法。

背景技術(shù)：

目前的數(shù)據(jù)緩存方案有redis集群方案及twitter方案。

redis集群方案，由于推出時間比較新，在我們的方案提出時還未成熟和大規(guī)模使用，它提供了一種預(yù)分配桶的哈希算法，靈活性上不如一致性哈希算法，故障轉(zhuǎn)移需要手動去分配。

twitter方案，它直接在redis協(xié)議層做了代理，它能靈活配置并支持例如一致性哈希這樣的自動算法，但是它是靜態(tài)的分布式集群，沒有支持redis節(jié)點(diǎn)自動故障轉(zhuǎn)移的功能，而且這個代理本身的故障轉(zhuǎn)移也需要開發(fā)自己去做。

將redis集群及twitter結(jié)合起業(yè)，它除了提供緩存服務(wù)之外，還提供了一套管理工具去做數(shù)據(jù)遷移、負(fù)載均衡等事情。

目前還提供了一整套完善的平臺化工具，支持大規(guī)模的集群化部署，但是它的部署比較重，需要部署數(shù)據(jù)庫、WEB系統(tǒng)，對于我們集群規(guī)模比較小的應(yīng)用場景來說，應(yīng)該起來不夠靈活。

以上方案或多或少都提供了分布式緩存的特性，但是他們都不是非常適合我們的應(yīng)用場景，我們希望分布式緩存滿足以下要求：

a)節(jié)點(diǎn)的哈希是動態(tài)和穩(wěn)定的，因此我們傾向于一致性哈?；蛘哳愃频墓Ｋ惴?；

b)同時，我們希望故障轉(zhuǎn)移能自動化完成，包括數(shù)據(jù)遷移等，不需要運(yùn)維手動介入；方案1、2、3都或多或少不能完全滿足自動故障轉(zhuǎn)移的要求。

c)另外，我們希望這套集群方案跟我們現(xiàn)有的支撐運(yùn)營平臺能比較好地兼容。方案4就比較重，集成我們內(nèi)部的平臺難度比較大。

因此，我亟需開發(fā)出一種通過最少的配置、實(shí)現(xiàn)了集群的高可用、自動化治理，并能實(shí)現(xiàn)數(shù)據(jù)遷移、負(fù)載均衡，動態(tài)和穩(wěn)定的zedis分布式緩存及服務(wù)器集群監(jiān)控方法。

技術(shù)實(shí)現(xiàn)要素：

本發(fā)明要解決的技術(shù)問題是提供一種zedis分布式緩存及服務(wù)器集群監(jiān)控方法，該zedis分布式緩存及服務(wù)器集群監(jiān)控方法通過最少的配置、實(shí)現(xiàn)了集群的高可用、自動化治理，并能實(shí)現(xiàn)數(shù)據(jù)遷移、負(fù)載均衡，動態(tài)和穩(wěn)定。

為解決上述技術(shù)問題，本發(fā)明提供了一種zedis分布式緩存及服務(wù)器集群監(jiān)控方法，提供zookeeper核心處理器、服務(wù)器集群監(jiān)控模塊、節(jié)點(diǎn)數(shù)據(jù)處理模塊、數(shù)據(jù)恢復(fù)模塊、客戶端、服務(wù)端及數(shù)據(jù)存儲服務(wù)器，所述zookeeper核心處理器包括服務(wù)器判斷模塊及服務(wù)器顯示模塊，所述zedis分布式緩存及服務(wù)器集群監(jiān)控方法包括以下步驟：

S1:所述服務(wù)器判斷模塊讀取所述服務(wù)器集群監(jiān)控模塊的redis服務(wù)器集群所需的完整信息；

S2:所述服務(wù)器判斷模塊將讀取到的信息發(fā)送給所述客戶端，所述客戶端將讀取redis服務(wù)器集群所需的完整信息，從每一個物理節(jié)點(diǎn)的完整信息抽取相對于其他物理節(jié)點(diǎn)唯一的信息，其中，所述信息包括ip地址與端口號；

S3:所述客戶端通過接收到的信息生成固定的多個key,通過負(fù)載均衡核心類ConsistentHash算法生成對應(yīng)多個hash碼，同一個信息生成的哈希碼全都映射到同一個物理節(jié)點(diǎn)，用哈希碼到物理節(jié)點(diǎn)的映射填充ConsistentHash的核心變量映射表形成哈希環(huán)；

S4:所述哈希環(huán)與所述數(shù)據(jù)存儲服務(wù)器連接完成數(shù)據(jù)備份與故障規(guī)避的讀寫過程；

S5:所述故障轉(zhuǎn)移處理模塊、服務(wù)器集群監(jiān)控模塊及zookeeper核心處理器通過數(shù)據(jù)備份、規(guī)避故障節(jié)點(diǎn)和數(shù)據(jù)恢復(fù)實(shí)現(xiàn)故障轉(zhuǎn)移；

S6:所述服務(wù)器集群監(jiān)控模塊對集群服務(wù)器進(jìn)行監(jiān)控，并將監(jiān)控得出的結(jié)果發(fā)送給zookeeper核心處理器，所述步驟S6的實(shí)現(xiàn)步驟包括：

S601:讀取zedis集群配置，建立物理節(jié)點(diǎn)對應(yīng)的檢測任務(wù)，把檢測出的可用性變化情況發(fā)送給客戶端；

S602:初始化集群，構(gòu)造服務(wù)器集群監(jiān)控模塊傳入客戶端的集群信息，所述服務(wù)器集群監(jiān)控模塊根據(jù)固定的配置規(guī)范讀取所述集群信息并初始化；

S603:所述服務(wù)器集群監(jiān)控模塊對每個讀取到的不同的物理節(jié)點(diǎn)構(gòu)造一個線程內(nèi)部類RedisPing任務(wù)，調(diào)用所述“檢測redis服務(wù)器是否可用”的策略的ping方法，檢測物理節(jié)點(diǎn)的可用性；

S604:根據(jù)監(jiān)控結(jié)果，判斷物理節(jié)點(diǎn)是否出現(xiàn)可用性變化，若物理節(jié)點(diǎn)出現(xiàn)可用性變化，從可用變?yōu)椴豢捎茫薷乃鰖ookeeper核心處理器配置并通知客戶端；若物理節(jié)點(diǎn)出現(xiàn)不可用性變化，從不可用變?yōu)榭捎?，先?shù)據(jù)恢復(fù)，然后再修改zookeeper核心處理器配置并通知所述客戶端；

其中，所述數(shù)據(jù)存儲服務(wù)器的數(shù)據(jù)存儲方式如下表所示：

其中，所述主節(jié)點(diǎn)為通過負(fù)載均衡核心類ConsistentHash算法找到的最近的物理節(jié)點(diǎn)，備節(jié)點(diǎn)是主節(jié)點(diǎn)的下一個節(jié)點(diǎn)。

優(yōu)選地，所述步驟“數(shù)據(jù)備份與故障規(guī)避的讀過程”的實(shí)現(xiàn)步驟包括：

S401:所述讀寫代理模塊根據(jù)key參數(shù)，通過哈希環(huán)找出主節(jié)點(diǎn)，并以此找到備節(jié)點(diǎn)；

S402:判斷主節(jié)點(diǎn)是否可用，如果主節(jié)點(diǎn)可用，則執(zhí)行步驟S403，如果主節(jié)點(diǎn)不可用但備節(jié)點(diǎn)可用，執(zhí)行步驟S404，如果主節(jié)點(diǎn)及備節(jié)點(diǎn)均不可用；

S403:往主節(jié)點(diǎn)主數(shù)據(jù)庫寫并往備節(jié)點(diǎn)的主數(shù)據(jù)庫寫入；

S404:往備節(jié)點(diǎn)的備用數(shù)據(jù)庫和臨時數(shù)據(jù)庫寫入；

S405:寫入其他可用節(jié)點(diǎn)的數(shù)據(jù)庫；

所述步驟“數(shù)據(jù)備份與故障規(guī)避的寫過程”的實(shí)現(xiàn)步驟包括：

S406:所述讀寫代理模塊根據(jù)key參數(shù)獲取主節(jié)點(diǎn)及備份節(jié)點(diǎn)；

S407:判斷主節(jié)點(diǎn)是否可用,如果主節(jié)點(diǎn)可用，執(zhí)行步驟S408，如果主節(jié)點(diǎn)不可用但備節(jié)點(diǎn)可用，執(zhí)行步驟S409,如果主節(jié)點(diǎn)及備節(jié)點(diǎn)均不可用，執(zhí)行步驟S410；

S408：從主節(jié)點(diǎn)讀??；

S409:從備節(jié)點(diǎn)讀取；

S410:從其他節(jié)點(diǎn)讀取。

優(yōu)選地，所述客戶端包括負(fù)載均衡處理模塊，所述步驟S3中的“負(fù)載均衡核心類ConsistentHash算法”包括：

所述負(fù)載均衡處理模塊通過MurMurHash2算法接收參數(shù)key，生成并返回哈希碼；

所述負(fù)載均衡處理模塊通過void_addNode算法接收節(jié)點(diǎn)S和一個原始參數(shù)key,用參數(shù)key生成多個哈希碼,并將所有的哈希碼全部映射到所述節(jié)點(diǎn)S，將映射存入TreeMap；

所述負(fù)載均衡處理模塊通過S_getClosestNode算法接收參數(shù)key,根據(jù)key生成hashCode，用TreeMap的tailMap算法，找到最近的節(jié)點(diǎn)并返回。

優(yōu)選地，所述服務(wù)器集群監(jiān)控模塊包括連接redis服務(wù)器所需的信息、表明節(jié)點(diǎn)可用性狀態(tài)的表量及檢測redis服務(wù)器是否可用的策略。

優(yōu)選地，所述檢測redis服務(wù)器是否可用的策略包括：初始化所述服務(wù)器集群監(jiān)控模塊并根據(jù)信息與redis服務(wù)器建立連接；

通過客戶端的ping方法檢測節(jié)點(diǎn)是否存活，再通過客戶端的set方法，檢查是否能正常存入數(shù)據(jù)，如果檢查均通過則返回服務(wù)器可用,否則返回服務(wù)器不可用；

連續(xù)N次調(diào)用pingOnce()，記錄調(diào)用成功或失敗比率并返回；

所述服務(wù)器集群監(jiān)控模塊先調(diào)用一次pingOnce(),若返回結(jié)果與所述服務(wù)器集群監(jiān)控模塊一致，則redis服務(wù)器可用性狀態(tài)無變化，并返回檢測結(jié)果，若首次檢測結(jié)果與所述服務(wù)器集群監(jiān)控模塊不一致,則調(diào)用checkStateRatio進(jìn)行判斷，以checkStateRatio返回結(jié)果為準(zhǔn)，返回檢測結(jié)果。

優(yōu)選地，所述哈希環(huán)包括Redis節(jié)點(diǎn)，Redis節(jié)點(diǎn)標(biāo)號到Redis節(jié)點(diǎn)本身的映射表、集群的最大標(biāo)號和最小標(biāo)號。

優(yōu)選地，還包括步驟：所述服務(wù)器集群監(jiān)控模塊對集群服務(wù)器進(jìn)行監(jiān)控，并將監(jiān)控得出的結(jié)果發(fā)送給zookeeper核心處理器，該步驟的實(shí)現(xiàn)步驟包括：

讀取zedis集群配置，建立物理節(jié)點(diǎn)對應(yīng)的檢測任務(wù)，把檢測出的可用性變化情況通過發(fā)送給客戶端；

初始化集群，構(gòu)造服務(wù)器集群監(jiān)控模塊傳入客戶端的集群信息，所述服務(wù)器集群監(jiān)控模塊根據(jù)固定的配置規(guī)范讀取所述集群信息并初始化；

所述服務(wù)器集群監(jiān)控模塊對每個讀取到的不同的物理節(jié)點(diǎn)構(gòu)造一個線程內(nèi)部類RedisPing任務(wù)，調(diào)用所述“檢測redis服務(wù)器是否可用”的策略的ping方法，檢測物理節(jié)點(diǎn)的可用性；

根據(jù)監(jiān)控結(jié)果，判斷物理節(jié)點(diǎn)是否出現(xiàn)可用性變化，若物理節(jié)點(diǎn)出現(xiàn)可用性變化，從可用變?yōu)椴豢捎?，修改所述zookeeper核心處理器配置并通知客戶端；若物理節(jié)點(diǎn)出現(xiàn)不可用性變化，從不可用變?yōu)榭捎茫葦?shù)據(jù)恢復(fù)，然后再修改zookeeper核心處理器配置并通知所述客戶端。

優(yōu)選地，所述步驟S5的實(shí)現(xiàn)步驟包括：

所述故障轉(zhuǎn)移處理模塊根據(jù)key參數(shù)生成哈希碼并找到主節(jié)點(diǎn)，然后找到主節(jié)點(diǎn)的備節(jié)點(diǎn)，對主備節(jié)點(diǎn)進(jìn)行相同的寫操作，主節(jié)點(diǎn)＝n,則備節(jié)點(diǎn)＝n+1,寫操作在主節(jié)點(diǎn)主數(shù)據(jù)庫空間和備節(jié)點(diǎn)的備數(shù)據(jù)庫空間一起進(jìn)行。

優(yōu)選地，所述步驟S5的“規(guī)避故障節(jié)點(diǎn)步驟”的實(shí)現(xiàn)步驟包括：

所述故障轉(zhuǎn)移處理模塊根據(jù)java代理攔截接口調(diào)用的數(shù)據(jù)，并通過key參數(shù)找到主節(jié)點(diǎn),判斷主節(jié)點(diǎn)是否可用，如果可用則在主節(jié)點(diǎn)上與數(shù)據(jù)存儲服務(wù)器進(jìn)行數(shù)據(jù)交換的工作；如果主節(jié)點(diǎn)不可用，則在備節(jié)點(diǎn)與數(shù)據(jù)存儲服務(wù)器進(jìn)行數(shù)據(jù)交換的工作；如果主節(jié)點(diǎn)和備節(jié)點(diǎn)均不可用，則在剩余的物理節(jié)點(diǎn)中,尋找可用的節(jié)點(diǎn)與數(shù)據(jù)存儲服務(wù)器進(jìn)行數(shù)據(jù)交換的工作。

優(yōu)選地，所述步驟S5的“數(shù)據(jù)恢復(fù)”的實(shí)現(xiàn)步驟包括：

判斷故障節(jié)點(diǎn)規(guī)避是否已經(jīng)完成，如果已經(jīng)完成，則進(jìn)行數(shù)據(jù)恢復(fù)，否則續(xù)費(fèi)進(jìn)行故障節(jié)點(diǎn)規(guī)避；

找出恢復(fù)正常的節(jié)點(diǎn)相對的主節(jié)點(diǎn)和備節(jié)點(diǎn)，假設(shè)主數(shù)據(jù)庫＝n,恢復(fù)節(jié)點(diǎn)＝n+2，恢復(fù)節(jié)點(diǎn)為目標(biāo)節(jié)點(diǎn)，主節(jié)點(diǎn)＝n+1,備節(jié)點(diǎn)＝n+3；從備節(jié)點(diǎn)臨時數(shù)據(jù)庫空間恢復(fù)數(shù)據(jù)到目標(biāo)節(jié)點(diǎn)主數(shù)據(jù)庫空間，然后清空備節(jié)點(diǎn)臨時數(shù)據(jù)庫空間,從主節(jié)點(diǎn)主數(shù)據(jù)庫空間恢復(fù)數(shù)據(jù)到目標(biāo)節(jié)點(diǎn)備用數(shù)據(jù)庫空間。

采用了上述方法之后，所述服務(wù)器判斷模塊讀取所述服務(wù)器集群監(jiān)控模塊的redis服務(wù)器集群所需的完整信息；所述服務(wù)器判斷模塊將讀取到的信息發(fā)送給所述客戶端，所述客戶端將讀取redis服務(wù)器集群所需的完整信息，從每一個物理節(jié)點(diǎn)的完整信息抽取相對于其他物理節(jié)點(diǎn)唯一的信息，其中，所述信息包括ip地址與端口號；所述客戶端通過接收到的信息生成固定的多個key,通過負(fù)載均衡核心類ConsistentHash算法生成對應(yīng)多個hash碼，同一個信息生成的哈希碼全都映射到同一個物理節(jié)點(diǎn)，用哈希碼到物理節(jié)點(diǎn)的映射填充ConsistentHash的核心變量映射表形成哈希環(huán)；所述哈希環(huán)與所述數(shù)據(jù)存儲服務(wù)器連接完成數(shù)據(jù)備份與故障規(guī)避的讀寫過程；所述故障轉(zhuǎn)移處理模塊、服務(wù)器集群監(jiān)控模塊及zookeeper核心處理器通過數(shù)據(jù)備份、規(guī)避故障節(jié)點(diǎn)和數(shù)據(jù)恢復(fù)實(shí)現(xiàn)故障轉(zhuǎn)移；該zedis分布式緩存及服務(wù)器集群監(jiān)控方法通過最少的配置、實(shí)現(xiàn)了集群的高可用、自動化治理，并能實(shí)現(xiàn)數(shù)據(jù)遷移、負(fù)載均衡，動態(tài)和穩(wěn)定，基于監(jiān)控的自動故障轉(zhuǎn)移機(jī)制，利用zookeeper核心處理器的分布式協(xié)調(diào)機(jī)制，對集群進(jìn)行監(jiān)控，從而實(shí)現(xiàn)自動實(shí)時故障轉(zhuǎn)移和數(shù)據(jù)恢復(fù)，服務(wù)器集群監(jiān)控模塊的監(jiān)控使用基于概率的故障檢測算法，既能抗抖動，又保障了實(shí)時性，對一致性哈希算法進(jìn)行擴(kuò)展優(yōu)化，實(shí)現(xiàn)數(shù)據(jù)自動備份，還有故障節(jié)點(diǎn)的自動恢復(fù)。

附圖說明

圖1是本發(fā)明的一種zedis分布式緩存及服務(wù)器集群監(jiān)控方法的整體模型示意圖；

圖2是一種zedis分布式緩存及服務(wù)器集群監(jiān)控方法的實(shí)現(xiàn)流程圖；

圖3是一種zedis分布式緩存及服務(wù)器集群監(jiān)控方法中的故障場景日記的示意圖；

圖4是一種zedis分布式緩存及服務(wù)器集群監(jiān)控方法中的服務(wù)器集群監(jiān)控場景日記的示意圖；

圖5是一種zedis分布式緩存及服務(wù)器集群監(jiān)控方法中的客戶端運(yùn)用場景日記的示意圖。

具體實(shí)施方式

為了使本發(fā)明的目的、技術(shù)方案及優(yōu)點(diǎn)更加清楚明白，以下結(jié)合附圖及實(shí)施例，對本發(fā)明進(jìn)行進(jìn)一步詳細(xì)說明。應(yīng)當(dāng)理解，此處所描述的具體實(shí)施例僅用于解釋本發(fā)明，并不用于限定本發(fā)明。

實(shí)施例1

請參閱圖1至圖2，圖1是本發(fā)明的一種zedis分布式緩存及服務(wù)器集群監(jiān)控方法的整體模型示意圖；圖2是與圖1的一種zedis分布式緩存及服務(wù)器集群監(jiān)控方法的實(shí)現(xiàn)流程圖。

本發(fā)明公開了一種zedis分布式緩存及服務(wù)器集群監(jiān)控方法，提供zookeeper核心處理器、服務(wù)器集群監(jiān)控模塊、節(jié)點(diǎn)數(shù)據(jù)處理模塊、數(shù)據(jù)恢復(fù)模塊、客戶端、服務(wù)端及數(shù)據(jù)存儲服務(wù)器，所述zookeeper核心處理器包括服務(wù)器判斷模塊及服務(wù)器顯示模塊，所述zedis分布式緩存及服務(wù)器集群監(jiān)控方法包括以下步驟：

S1:所述服務(wù)器判斷模塊讀取所述服務(wù)器集群監(jiān)控模塊的redis服務(wù)器集群所需的完整信息；

S2:所述服務(wù)器判斷模塊將讀取到的信息發(fā)送給所述客戶端，所述客戶端將讀取redis服務(wù)器集群所需的完整信息，從每一個物理節(jié)點(diǎn)的完整信息抽取相對于其他物理節(jié)點(diǎn)唯一的信息，其中，所述信息包括ip地址與端口號；

S3:所述客戶端通過接收到的信息生成固定的多個key,通過負(fù)載均衡核心類ConsistentHash算法生成對應(yīng)多個hash碼，同一個信息生成的哈希碼全都映射到同一個物理節(jié)點(diǎn)，用哈希碼到物理節(jié)點(diǎn)的映射填充ConsistentHash的核心變量映射表形成哈希環(huán)；

S4:所述哈希環(huán)與所述數(shù)據(jù)存儲服務(wù)器連接完成數(shù)據(jù)備份與故障規(guī)避的讀寫過程；

S5:所述故障轉(zhuǎn)移處理模塊、服務(wù)器集群監(jiān)控模塊及zookeeper核心處理器通過數(shù)據(jù)備份、規(guī)避故障節(jié)點(diǎn)和數(shù)據(jù)恢復(fù)實(shí)現(xiàn)故障轉(zhuǎn)移；

S6:所述服務(wù)器集群監(jiān)控模塊對集群服務(wù)器進(jìn)行監(jiān)控，并將監(jiān)控得出的結(jié)果發(fā)送給zookeeper核心處理器，所述步驟S6的實(shí)現(xiàn)步驟包括：

S601:讀取zedis集群配置，建立物理節(jié)點(diǎn)對應(yīng)的檢測任務(wù)，把檢測出的可用性變化情況發(fā)送給客戶端；

S602:初始化集群，構(gòu)造服務(wù)器集群監(jiān)控模塊傳入客戶端的集群信息，所述服務(wù)器集群監(jiān)控模塊根據(jù)固定的配置規(guī)范讀取所述集群信息并初始化；

S603:所述服務(wù)器集群監(jiān)控模塊對每個讀取到的不同的物理節(jié)點(diǎn)構(gòu)造一個線程內(nèi)部類RedisPing任務(wù)，調(diào)用所述“檢測redis服務(wù)器是否可用”的策略的ping方法，檢測物理節(jié)點(diǎn)的可用性；

S604:根據(jù)監(jiān)控結(jié)果，判斷物理節(jié)點(diǎn)是否出現(xiàn)可用性變化，若物理節(jié)點(diǎn)出現(xiàn)可用性變化，從可用變?yōu)椴豢捎?，修改所述zookeeper核心處理器配置并通知客戶端；若物理節(jié)點(diǎn)出現(xiàn)不可用性變化，從不可用變?yōu)榭捎?，先?shù)據(jù)恢復(fù)，然后再修改zookeeper核心處理器配置并通知所述客戶端；

所述步驟“數(shù)據(jù)備份與故障規(guī)避的讀過程”的實(shí)現(xiàn)步驟包括：

S401:所述讀寫代理模塊根據(jù)key參數(shù)，通過哈希環(huán)找出主節(jié)點(diǎn)，并以此找到備節(jié)點(diǎn)；

S402:判斷主節(jié)點(diǎn)是否可用，如果主節(jié)點(diǎn)可用，則執(zhí)行步驟S403，如果主節(jié)點(diǎn)不可用但備節(jié)點(diǎn)可用，執(zhí)行步驟S404，如果主節(jié)點(diǎn)及備節(jié)點(diǎn)均不可用；

S403:往主節(jié)點(diǎn)主數(shù)據(jù)庫寫并往備節(jié)點(diǎn)的主數(shù)據(jù)庫寫入；

S404:往備節(jié)點(diǎn)的備用數(shù)據(jù)庫和臨時數(shù)據(jù)庫寫入；

S405:寫入其他可用節(jié)點(diǎn)的數(shù)據(jù)庫；

所述步驟“數(shù)據(jù)備份與故障規(guī)避的寫過程”的實(shí)現(xiàn)步驟包括：

S406:所述讀寫代理模塊根據(jù)key參數(shù)獲取主節(jié)點(diǎn)及備份節(jié)點(diǎn)；

S407:判斷主節(jié)點(diǎn)是否可用,如果主節(jié)點(diǎn)可用，執(zhí)行步驟S408，如果主節(jié)點(diǎn)不可用但備節(jié)點(diǎn)可用，執(zhí)行步驟S409,如果主節(jié)點(diǎn)及備節(jié)點(diǎn)均不可用，執(zhí)行步驟S410；

S408：從主節(jié)點(diǎn)讀??；

S409:從備節(jié)點(diǎn)讀??；

S410:從其他節(jié)點(diǎn)讀?。?/p>

其中，所述數(shù)據(jù)存儲服務(wù)器的數(shù)據(jù)存儲方式如下表所示：

其中，所述主節(jié)點(diǎn)為通過負(fù)載均衡核心類ConsistentHash算法找到的最近的物理節(jié)點(diǎn)，備節(jié)點(diǎn)是主節(jié)點(diǎn)的下一個節(jié)點(diǎn)。

所述客戶端包括負(fù)載均衡處理模塊，所述步驟S3中的“負(fù)載均衡核心類ConsistentHash算法”包括：

所述負(fù)載均衡處理模塊通過MurMurHash2算法接收參數(shù)key，生成并返回哈希碼；

所述負(fù)載均衡處理模塊通過void_addNode算法接收節(jié)點(diǎn)S和一個原始參數(shù)key,用參數(shù)key生成多個哈希碼,并將所有的哈希碼全部映射到所述節(jié)點(diǎn)S，將映射存入TreeMap；

所述負(fù)載均衡處理模塊通過S_getClosestNode算法接收參數(shù)key,根據(jù)參數(shù)key生成hashCode，用TreeMap的tailMap算法，找到最近的節(jié)點(diǎn)并返回。

所述服務(wù)器集群監(jiān)控模塊包括連接redsi服務(wù)器所需的信息、表明節(jié)點(diǎn)可用性狀態(tài)的表量及檢測redis服務(wù)器是否可用的策略。

所述檢測redis服務(wù)器是否可用的策略包括：初始化所述服務(wù)器集群監(jiān)控模塊并根據(jù)信息與redis服務(wù)器建立連接；

通過客戶端的ping方法檢測節(jié)點(diǎn)是否存活，再通過客戶端的set方法，檢查是否能正常存入數(shù)據(jù)，如果檢查均通過則返回服務(wù)器可用,否則返回服務(wù)器不可用；

連續(xù)N次調(diào)用pingOnce()，記錄調(diào)用成功或失敗比率并返回；

所述服務(wù)器集群監(jiān)控模塊先調(diào)用一次pingOnce(),若返回結(jié)果與所述服務(wù)器集群監(jiān)控模塊一致，則redis服務(wù)器可用性狀態(tài)無變化，并返回檢測結(jié)果，若首次檢測結(jié)果與所述服務(wù)器集群監(jiān)控模塊不一致,則調(diào)用checkStateRatio進(jìn)行判斷，以checkStateRatio返回結(jié)果為準(zhǔn)，返回檢測結(jié)果。

在本實(shí)施例中，所述哈希環(huán)包括Redis節(jié)點(diǎn)、Redis節(jié)點(diǎn)標(biāo)號到Redis節(jié)點(diǎn)本身的映射表、集群的最大標(biāo)號和最小標(biāo)號。

所述步驟S5的實(shí)現(xiàn)步驟包括：

所述故障轉(zhuǎn)移處理模塊根據(jù)key參數(shù)生成哈希碼并找到主節(jié)點(diǎn)，然后找到主節(jié)點(diǎn)的備節(jié)點(diǎn)，對主備節(jié)點(diǎn)進(jìn)行相同的寫操作，主節(jié)點(diǎn)＝n,則備節(jié)點(diǎn)＝n+1,寫操作在主節(jié)點(diǎn)主數(shù)據(jù)庫空間和備節(jié)點(diǎn)的備數(shù)據(jù)庫空間一起進(jìn)行。

所述步驟S5的“規(guī)避故障節(jié)點(diǎn)步驟”的實(shí)現(xiàn)步驟包括：

所述故障轉(zhuǎn)移處理模塊根據(jù)java代理攔截接口調(diào)用的數(shù)據(jù)，并通過key參數(shù)找到主節(jié)點(diǎn),判斷主節(jié)點(diǎn)是否可用，如果可用則在主節(jié)點(diǎn)上與數(shù)據(jù)存儲服務(wù)器進(jìn)行數(shù)據(jù)交換的工作；如果主節(jié)點(diǎn)不可用，則在備節(jié)點(diǎn)與數(shù)據(jù)存儲服務(wù)器進(jìn)行數(shù)據(jù)交換的工作；如果主節(jié)點(diǎn)和備節(jié)點(diǎn)均不可用，則在剩余的物理節(jié)點(diǎn)中,尋找可用的節(jié)點(diǎn)與數(shù)據(jù)存儲服務(wù)器進(jìn)行數(shù)據(jù)交換的工作。

所述步驟S5的“數(shù)據(jù)恢復(fù)”的實(shí)現(xiàn)步驟包括：

判斷故障節(jié)點(diǎn)規(guī)避是否已經(jīng)完成，如果已經(jīng)完成，則進(jìn)行數(shù)據(jù)恢復(fù)，否則繼續(xù)進(jìn)行故障節(jié)點(diǎn)規(guī)避；

找出恢復(fù)正常的節(jié)點(diǎn)相對的主節(jié)點(diǎn)和備節(jié)點(diǎn)，假設(shè)主數(shù)據(jù)庫＝n,恢復(fù)節(jié)點(diǎn)＝n+2，恢復(fù)節(jié)點(diǎn)為目標(biāo)節(jié)點(diǎn)，主節(jié)點(diǎn)＝n+1,備節(jié)點(diǎn)＝n+3；從備節(jié)點(diǎn)臨時數(shù)據(jù)庫空間恢復(fù)數(shù)據(jù)到目標(biāo)節(jié)點(diǎn)主數(shù)據(jù)庫空間，然后清空備節(jié)點(diǎn)臨時數(shù)據(jù)庫空間,從主節(jié)點(diǎn)主數(shù)據(jù)庫空間恢復(fù)數(shù)據(jù)到目標(biāo)節(jié)點(diǎn)備用數(shù)據(jù)庫空間。

本實(shí)施例，模擬實(shí)驗(yàn)過程及部分實(shí)驗(yàn)結(jié)果如下文所示。

(1)故障場景

故障測試模擬了一個故障場景，用程序在本地上啟動幾個redis服務(wù)器，并且按照一定配置不間斷地終結(jié)服務(wù)器進(jìn)程和重啟服務(wù)器，本場景中同一時間只有一個服務(wù)器會被終結(jié)，服務(wù)器故障場景如下圖3程序的打印記錄。

(2)服務(wù)器集群監(jiān)控，布置好故障場景后，啟動服務(wù)器集群監(jiān)控模塊，檢測redis服務(wù)器可用性，改寫zookeeper核心處理器通知客戶端，并且負(fù)責(zé)數(shù)據(jù)恢復(fù)，啟動服務(wù)器集群監(jiān)控模塊應(yīng)對服務(wù)器上下線的操作如圖4的日志記錄。

(3)客戶端運(yùn)用場景

如圖5的日記所示，在故障場景下，和服務(wù)器集群監(jiān)控模塊的協(xié)助下，開啟程序模擬客戶端使用zedis，按照一定比例不斷地讀寫redis集群數(shù)據(jù)，記錄并實(shí)時打印出成功讀寫的百分比，在本故障場景下，寫成功率會是100％，這是客戶端讀寫模擬場景簡單單一的效果。

采用了上述方法之后，所述服務(wù)器判斷模塊讀取所述服務(wù)器集群監(jiān)控模塊的redis服務(wù)器集群所需的完整信息；所述服務(wù)器判斷模塊將讀取到的信息發(fā)送給所述客戶端，所述客戶端將讀取redis服務(wù)器集群所需的完整信息，從每一個物理節(jié)點(diǎn)的完整信息抽取相對于其他物理節(jié)點(diǎn)唯一的信息，其中，所述信息包括ip地址與端口號；所述客戶端通過接收到的信息生成固定的多個key,通過負(fù)載均衡核心類ConsistentHash算法生成對應(yīng)多個hash碼，同一個信息生成的哈希碼全都映射到同一個物理節(jié)點(diǎn)，用哈希碼到物理節(jié)點(diǎn)的映射填充ConsistentHash的核心變量映射表形成哈希環(huán)；所述哈希環(huán)與所述數(shù)據(jù)存儲服務(wù)器連接完成數(shù)據(jù)備份與故障規(guī)避的讀寫過程；所述故障轉(zhuǎn)移處理模塊、服務(wù)器集群監(jiān)控模塊及zookeeper核心處理器通過數(shù)據(jù)備份、規(guī)避故障節(jié)點(diǎn)和數(shù)據(jù)恢復(fù)實(shí)現(xiàn)故障轉(zhuǎn)移；該zedis分布式緩存及服務(wù)器集群監(jiān)控方法通過最少的配置、實(shí)現(xiàn)了集群的高可用、自動化治理，并能實(shí)現(xiàn)數(shù)據(jù)遷移、負(fù)載均衡，動態(tài)和穩(wěn)定，基于監(jiān)控的自動故障轉(zhuǎn)移機(jī)制，利用zookeeper核心處理器的分布式協(xié)調(diào)機(jī)制，對集群進(jìn)行監(jiān)控，從而實(shí)現(xiàn)自動實(shí)時故障轉(zhuǎn)移和數(shù)據(jù)恢復(fù)，服務(wù)器集群監(jiān)控模塊的監(jiān)控使用基于概率的故障檢測算法，既能抗抖動，又保障了實(shí)時性，對一致性哈希算法進(jìn)行擴(kuò)展優(yōu)化，實(shí)現(xiàn)數(shù)據(jù)自動備份，還有故障節(jié)點(diǎn)的自動恢復(fù)。

同時，應(yīng)當(dāng)理解的是，以上僅為本發(fā)明的優(yōu)選實(shí)施例，不能因此限制本發(fā)明的專利范圍，凡是利用本發(fā)明說明書及附圖內(nèi)容所作的等效結(jié)構(gòu)或等效實(shí)現(xiàn)方法，或直接或間接運(yùn)用在其他相關(guān)的技術(shù)領(lǐng)域，均同理包括在本發(fā)明的專利保護(hù)范圍內(nèi)。