一種云平臺下可擴展的分布式協調服務管理方法
【專利摘要】本發明公開了一種云平臺下可擴展的分布式協調服務管理方法，包括：以中間節點交叉樹林的組織方式對分布式集群的所有節點進行初始化，所有成員節點根據來自中心管理節點的全局網絡拓撲結構查詢出本節點的父子成員節點信息，所有父子成員節點之間以心跳機制進行信息同步和通信，成員節點判斷是否從其它成員節點接收到成員狀態變更信息，如果接收到則進一步判斷該成員狀態變更信息指示成員減少還是增加，如果是減少則成員節點如果收到成員減少的成員狀態變更信息后，根據中斷心跳封裝出一個成員狀態變更信息，并將其發送到中心管理節點。本發明更新服務的效率不會在擴展過程中急劇下降，因此更適合大規模的云平臺和數據處理系統。
【專利說明】一種云平臺下可擴展的分布式協調服務管理方法
【技術領域】
[0001]本發明屬于云計算【技術領域】，更具體地，涉及一種云平臺下可擴展的分布式協調服務管理方法。
【背景技術】
[0002]云計算和大數據盛行的今天，云服務和數據處理分析通常建立在萬級甚至百萬級規模的機器平臺上。在如此規模的集群中，節點失效、磁盤錯誤甚至網絡失效等問題出現概率較高，這給服務容錯和可靠性提出了很大的挑戰，對此通常采用協調服務來解決問題。協調服務系統是在不改變原有系統架構下解決容錯的問題、保證可靠服務的最佳解決方案，通過可靠的協調服務來實現集群的可靠管理、分布式算法以及事件通知等機制。在現有的協調服務系統中，Google實現了鎖服務系統Chubby,用于為諸如BigTable、Percolator>GFS的分布式系統提供諸如元數據管理、命名服務、失效監控等可靠服務；Yahoo !開發的開源協調服務系統Zookeeper，通過異步原語的接口實現諸如分布式隊列、分布式鎖、訂閱發布模型等可靠的服務。其中，Zookeeper是Chubby —個開源的實現,它是一個針對大型分布式系統的可靠協調系統，提供諸如配置維護、名字服務、分布式同步、組服務的協調服務。其設計目標是封裝復雜易出錯的關鍵服務，將簡單易用的接口和性能高效、功能穩定的系統提供給用戶。其以快速Paxos算法為基礎同時采用多個服務器同時服務，中心管理節點協調內部一致性，從而解決了 Chubby的單點瓶頸問題。
[0003]但是隨著云技術處理場景的多樣化以及云平臺規模的不斷擴大，云平臺對協調服務的要求越來越高，需求也越來越多。而現有的分布式協調服務系統大都采用中心化的架構來協調數據的一致性，中心管理節點所承擔的工作比其他節點要多，當協調服務增多時，中心節點比其他節點更容易達到瓶頸，導致整個一致性過程性能下降，其更新性能也會隨著系統的擴展下降。另外，這種中`心化協調方式會因為中心節點的失效而出現短暫的服務中斷，服務失效的恢復時間會隨著節點的增多而變長，存在擴展過程中可靠性和可用性問題。
[0004]由此可見，協調服務的動態擴展在大規模云平臺扮演非常大的作用，但也是傳統協調服務系統尚未解決的問題。云計算發展至今，云平臺的規模不斷的擴大，協調服務的要求不斷增多，因此能否根據當前系統的規模和負載來動態調整協調服務系統的規模是非常有價值的事情，也是一件很有挑戰的研究內容。因此，如何實現可動態擴展的、高性能的和高可靠的協調服務是當今云平臺下協調服務系統急需解決的首要問題。

【發明內容】

[0005]針對現有技術的以上缺陷或改進需求，本發明提供了一種云平臺下可擴展的分布式協調服務管理方法，其目的在于，解決現有協調服務系統中存在的擴展性差和管理過程效率低下的技術問題。
[0006]為實現上述目的，按照本發明的一個方面，提供了一種云平臺下可擴展的分布式協調服務管理方法，包括以下步驟:
[0007]( I)以中間節點交叉樹林的組織方式對分布式集群的所有節點進行初始化；
[0008](2)所有成員節點根據來自中心管理節點的全局網絡拓撲結構查詢出本節點的父子成員節點信息，所有父子成員節點之間以心跳機制進行信息同步和通信；
[0009](3)成員節點判斷是否從其它成員節點接收到成員狀態變更信息，如果接收到則進一步判斷該成員狀態變更信息指示成員減少還是增加，如果是減少則轉入步驟(4)，如果是增加則轉入步驟(7)，如果沒有接收到則持續監聽來自其它成員節點的成員狀態變更信息；
[0010](4)成員節點判斷是否接收到來自父節點或子節點的心跳信息，如果接收到則根據心跳信息封裝出一個成員狀態變更信息，并將其發送到中心管理節點，然后轉入步驟(5)，否則該成員節點繼續監聽來自父節點或子節點的心跳信息；
[0011](5)中心管理節點判斷來自成員節點的成員狀態變更信息是否正確，如果正確則更新全局網絡拓撲結構，并將更新后的全局網絡拓撲結構發送到所有的根成員節點，再由根成員節點分發給它的子孫成員節點，然后轉入步驟(6)，否則等待接收來自其他成員節點的成員狀態變更信息；
[0012](6)所有成員節點根據更新后的全局網絡拓撲圖更新其本地的網絡拓撲結構；
[0013](7)成員節點根據成員狀態變更信息判斷是否有新的成員節點請求獲取全局網絡拓撲結構，若是則向中心管理節點發送報告信息，以請求中心管理節點為該新的成員節點分配顏色信息，然后轉入步驟(8)，否則成員節點繼續監聽是否有成員狀態變更信息；
[0014](8)中心管理節點根據報告信息為該新成員節點分配顏色信息，并更新其自身的全局網絡拓撲結構，并將新后的全局網絡拓撲結構發送到新的成員節點，轉入步驟(9)，同時也將更新后的全局網絡拓撲結構分發給所有樹的根成員節點，再有根成員節點分發給它所有的子孫成員節點，轉入步驟(6)；
[0015](9)新的成員節點根據來自中心管理節點的更新后的全局網絡拓撲結構更新其本地的網絡拓撲結構，并根據更新后的網絡拓撲結構查詢其父子成員節點信息，并與其父子成員節點建立心跳聯系。
[0016]優選地，步驟(I)具體包括以下子步驟:
[0017](1-1)分布式集群中的中心管理節點接收管理員對分布式集群所有節點的命名nodel, node2,..., noden,其中η為分布式集群中節點的總數,并將該命名信息同步到所有節點；
[0018](1-2)中心管理節點對分布式集群的顏色集、最大樹數和最大子節點數進行配置，并將配置結果作為限制參數轉發給所有成員節點，用于對整個分布式集群的拓撲結構進行限定；
[0019](1-3)中心管理節點在分布式集群啟動后將顏色集分配給所有節點，然后根據每個節點的顏色、IP地址以及步驟(1-2)中配置的最大樹數和最大子節點數構建由多棵樹組成的全局網絡拓撲圖，如圖1所示；
[0020](1-4)中心管理節點為全局網絡拓撲結構設定版本格式、初始版本號以及遞增方式，并將該全局網絡拓撲結構分發給所有樹的根成員節點，再有根成員節點分發給它的子孫成員節點；[0021]優選地，編號為nodel的節點即為中心管理節點，其它節點為成員節點。
[0022]優選地，步驟(1-3)中全局網絡拓撲的構建過程遵循以下原則:
[0023]( 1-3-1)相同顏色的節點集中在一棵樹的根節點或中間節點，且分散在其它樹的葉子節點中；
[0024](1-3-2)—個節點可以同時出現在多棵樹中，但每個節點只能在一棵樹中充當根節點或者中間節點；
[0025](1-3-3 )新節點應該插入到與之同顏色的樹中最靠近根節點的節點中，且該節點中子節點的數目未超過最大子節點數；
[0026](1-3-4) 一個節點的子節點數目達到最大子節點數時,新插入的節點應該插入到該節點的子樹中，并且被插入的子樹是所有子樹中高度最矮或者子孫節點數目最少的；
[0027](1-3-5)當全局網絡拓撲結構中樹的總數達到最大樹數時，如果再有新節點加入分布式集群，則不為該新節點創建新的樹結構，而是將該新節點插入已有的樹結構中。
[0028]優選地，步驟(3)中，成員節點與其他某個成員節點的心跳機制突然中斷時，表明該成員節點收到了成員減少的成員狀態變更信息，成員節點收到了它所維護的全局網絡拓撲結構中不存在的新的成員節點的心跳信息時，表明該成員節點收到了成員增加的成員狀態變更信息。
[0029]優選地，步驟(5)中，如果中心管理節點同時接收到來自一個以上成員節點的成員狀態變更信息，則表示成員狀態變更信息是正確的，如果僅接收到來自一個成員節點的成員狀態變更信息，則表示成員狀態變更信息是錯誤的。
[0030]總體而言，通過本發明所構思的以上技術方案與現有技術相比，能夠取得下列有益效果:
[0031]1、擴展性好:本發明由于采用了步驟(I)中的成員組織方式和步驟(3)中對成員節點變更的自動監聽機制，使得分布式協調服務系統在有新的成員加入和舊成員移出時能實時動態的捕捉到這一變化并做出相應的調整。因此，實現了分布式協調服務系統的動態擴展。
[0032]2、可靠性:由于采用了步驟(I)中的成員組織方式以及以版本號命名的網絡拓撲結構，簡化了整個協調服務系統的信息同步的過程。該種成員組織方式中節點的交叉冗余特性，使得數據的分發也是冗余的，所以當有節點失效時，也能將數據準確可靠地同步到所有成員節點。
[0033]3、高效性:步驟(I)和步驟(5)中，所有數據的同步以及全局網絡拓撲結構的分發都是由中心管理節點首先分發給每棵樹的根節點，再由根節點分發給它的子孫節點，將中心管理節點的負載分層次的分擔給每棵樹的根節點，避免了中心管理節點因負載過大性能性能瓶頸。
[0034]4最優性:步驟(I)中，在中心管理節點上對全局網絡拓撲結構中對樹的數量以及節點的最大子節點數進行限制，從而控制的樹的高度和維度，保證了每棵樹的負載均衡，提高協調服務系統的整體性能。
【專利附圖】

【附圖說明】
[0035]圖1是本發明中間節點交叉樹林的結構示意圖。[0036]圖2是本發明云平臺下可擴展的分布式協調服務管理方法的流程圖。
【具體實施方式】
[0037]為了使本發明的目的、技術方案及優點更加清楚明白，以下結合附圖及實施例，對本發明進行進一步詳細說明。應當理解，此處所描述的具體實施例僅僅用以解釋本發明，并不用于限定本發明。此外，下面所描述的本發明各個實施方式中所涉及到的技術特征只要彼此之間未構成沖突就可以相互組合。
[0038]本發明的整體思路在于，對協調服務系統的成員采用中間節點交叉樹林的組織方式，同時在對協調服務系統網絡拓撲結構的構建過程中，對樹的高度和維度進行限定，保證了系統整體的負載均衡。在系統的管理過程中，父子節點間的心跳監聽機制能使得協調服務系統實時動態的感知到系統成員節點的變化，從而實現協調服務系統的動態擴展。數據分發和同步過程的冗余分發保證了系統可靠性。
[0039]本發明云平臺下可擴展的分布式協調服務管理方法包括以下步驟:
[0040](I)以中間節點交叉樹林的組織方式對分布式集群的所有節點進行初始化，具體包括以下子步驟:
[0041](1-1)分布式集群中的中心管理節點接收管理員對分布式集群所有節點的命名nodel, node2,..., noden,其中η為分布式集群中節點的總數，并將該命名信息同步到所有節點；具體而言，默認情況下編號為nodel的節點即為中心管理節點，其它節點為成員節
占.[0042](1-2 )中心管理節點對分布式集群的顏色集(Co I or_Set)、最大樹數(Max_Co I or_Num)和最大子節點數(Max_Children_Size)進行配置，并將配置結果作為限制參數轉發給所有成員節點，用于對整個分布式集群的拓撲結構進行限定；具體而言，顏色集、最大樹數和最大子節點數是由分布式集群的規模決定；
[0043](1-3)中心管理節點在分布式集群啟動后將顏色集分配給所有節點，然后根據每個節點的顏色、IP地址以及步驟(1-2)中配置的最大樹數和最大子節點數構建由多棵樹組成的全局網絡拓撲圖，如圖1所示；具體而言，全局網絡拓撲的構建過程遵循以下原則:
[0044](1-3-1)相同顏色的節點集中在一棵樹的根節點或中間節點，且分散在其它樹的葉子節點中；
[0045](1-3-2)—個節點可以同時出現在多棵樹中，但每個節點只能在一棵樹中充當根節點或者中間節點；
[0046]( 1-3-3 )新節點應該插入到與之同顏色的樹中最靠近根節點的節點中，且該節點中子節點的數目未超過最大子節點數；
[0047](1-3-4) 一個節點的子節點數目達到最大子節點數時,新插入的節點應該插入到該節點的子樹中，并且被插入的子樹是所有子樹中高度最矮或者子孫節點數目最少的；
[0048](1-3-5)當全局網絡拓撲結構中樹的總數達到最大樹數時，如果再有新節點加入分布式集群，則不為該新節點創建新的樹結構，而是將該新節點插入已有的樹結構中；
[0049](1-4)中心管理節點為全局網絡拓撲結構設定版本格式、初始版本號以及遞增方式，并將該全局網絡拓撲結構分發給所有樹的根成員節點，再有根成員節點分發給它的子孫成員節點；[0050]步驟(I)的優點在于，避免了中心化組織方式易形成的瓶頸問題，同時通過參數限制可以保證每棵樹的高度及節點數目近似一致，也就保證了每顆樹的負載是近似均衡的，且每棵樹中的事務處理時間是相似的，從而保證了全局數據提交的效率。
[0051](2)所有成員節點根據來自中心管理節點的全局網絡拓撲結構查詢出本節點的父子成員節點信息，所有父子成員節點之間以心跳機制進行信息同步和通信；
[0052](3)成員節點判斷是否從其它成員節點接收到成員狀態變更信息，如果接收到則進一步判斷該成員狀態變更信息指示成員減少還是增加，如果是減少則轉入步驟(4)，如果是增加則轉入步驟(7)，如果沒有接收到則持續監聽來自其它成員節點的成員狀態變更信息；具體而言，成員節點與其他某個成員節點的心跳機制突然中斷表明該成員節點收到了成員減少的成員狀態變更信息，成員節點收到了它所維護的全局網絡拓撲結構中不存在的新的成員節點的心跳信息時表明該成員節點收到了成員增加的成員狀態變更信息。
[0053](4)成員節點判斷是否接收到來自父節點或子節點的心跳信息(即在拓撲結構中，其父節點或者子節點在指定的時間內通過心跳機制報告其生命存活狀態)，如果接收到則根據心跳信息封裝出一個成員狀態變更信息，并將其發送到中心管理節點，然后轉入步驟
(5)，否則該成員節點繼續監聽來自父節點或子節點的心跳信息；
[0054](5)中心管理節點判斷來自成員節點的成員狀態變更信息是否正確，如果正確則更新全局網絡拓撲結構，并將更新后的全局網絡拓撲結構發送到所有的根成員節點，再由根成員節點分發給它的子孫成員節點，然后轉入步驟(6)，否則等待接收來自其他成員節點的成員狀態變更信息；具體而言，如果中心管理節點同時接收到來自一個以上成員節點的成員狀態變更信息，則表示成員狀態變更信息是正確的，如果僅接收到來自一個成員節點的成員狀態變更信息，則表示成員狀態變更信息是錯誤的；
[0055]步驟(5)的優點在于，中心管理節點可以根據接收到的成員狀態變更信息的條數來判斷這個成員狀態變更信息是由于網絡狀況不佳造成的還是真的有成員節點變更，從而保證的系統擴展過程中的正確性和可靠性。
[0056](6)所有成員節點根據更新后的全局網絡拓撲圖更新其本地的網絡拓撲結構；
[0057](7)成員節點根據成員狀態變更信息判斷是否有新的成員節點請求獲取全局網絡拓撲結構，若是則向中心管理節點發送報告信息，以請求中心管理節點為該新的成員節點分配顏色信息，然后轉入步驟(8)，否則成員節點繼續監聽是否有成員狀態變更信息；
[0058](8)中心管理節點根據報告信息為該新成員節點分配顏色信息，并更新其自身的全局網絡拓撲結構，并將新后的全局網絡拓撲結構發送到新的成員節點，轉入步驟(9)，同時也將更新后的全局網絡拓撲結構分發給所有樹的根成員節點，再有根成員節點分發給它所有的子孫成員節點，轉入步驟(6)；
[0059]步驟(8)的優點在于，在全局網絡拓撲結構發生更新后，對于更新的全局網絡拓撲結構的分發采用分層的分發機制，可以降低中心管理節點的負載，降低延遲，提高系統的效率。
[0060](9)新的成員節點根據來自中心管理節點的更新后的全局網絡拓撲結構更新其本地的網絡拓撲結構，并根據更新后的網絡拓撲結構查詢其父子成員節點信息，并與其父子成員節點建立心跳聯系。
[0061]本領域的技術人員容易理解，以上所述僅為本發明的較佳實施例而已，并不用以限制本發明，凡在本發明的精神和原則之內所作的任何修改、等同替換和改進等，均應包含在本發明的保護范圍之內。
【權利要求】
1.一種云平臺下可擴展的分布式協調服務管理方法，其特征在于，包括以下步驟: (I)以中間節點交叉樹林的組織方式對分布式集群的所有節點進行初始化； (2 )所有成員節點根據來自中心管理節點的全局網絡拓撲結構查詢出本節點的父子成員節點信息，所有父子成員節點之間以心跳機制進行信息同步和通信； (3)成員節點判斷是否從其它成員節點接收到成員狀態變更信息，如果接收到則進一步判斷該成員狀態變更信息指示成員減少還是增加，如果是減少則轉入步驟(4)，如果是增加則轉入步驟(7)，如果沒有接收到則持續監聽來自其它成員節點的成員狀態變更信息； (4)成員節點判斷是否接收到來自父節 點或子節點的心跳信息，如果接收到則根據心跳信息封裝出一個成員狀態變更信息，并將其發送到中心管理節點，然后轉入步驟(5)，否則該成員節點繼續監聽來自父節點或子節點的心跳信息； (5)中心管理節點判斷來自成員節點的成員狀態變更信息是否正確，如果正確則更新全局網絡拓撲結構，并將更新后的全局網絡拓撲結構發送到所有的根成員節點，再由根成員節點分發給它的子孫成員節點，然后轉入步驟(6)，否則等待接收來自其他成員節點的成員狀態變更信息； (6)所有成員節點根據更新后的全局網絡拓撲圖更新其本地的網絡拓撲結構； (7)成員節點根據成員狀態變更信息判斷是否有新的成員節點請求獲取全局網絡拓撲結構，若是則向中心管理節點發送報告信息，以請求中心管理節點為該新的成員節點分配顏色信息，然后轉入步驟(8)，否則成員節點繼續監聽是否有成員狀態變更信息。 (8)中心管理節點根據報告信息為該新成員節點分配顏色信息，并更新其自身的全局網絡拓撲結構，并將新后的全局網絡拓撲結構發送到新的成員節點，轉入步驟(9)，同時也將更新后的全局網絡拓撲結構分發給所有樹的根成員節點，再有根成員節點分發給它所有的子孫成員節點，轉入步驟(6)； (9)新的成員節點根據來自中心管理節點的更新后的全局網絡拓撲結構更新其本地的網絡拓撲結構，并根據更新后的網絡拓撲結構查詢其父子成員節點信息，并與其父子成員節點建立心跳聯系。
2.根據權利要求1所述的分布式協調服務管理方法，其特征在于，步驟(1)具體包括以下子步驟: (1-1)分布式集群中的中心管理節點接收管理員對分布式集群所有節點的命名nodel，node2,…，noden，其中η為分布式集群中節點的總數，并將該命名信息同步到所有節點； (1-2)中心管理節點對分布式集群的顏色集、最大樹數和最大子節點數進行配置，并將配置結果作為限制參數轉發給所有成員節點，用于對整個分布式集群的拓撲結構進行限定; (1-3)中心管理節點在分布式集群啟動后將顏色集分配給所有節點，然后根據每個節點的顏色、IP地址以及步驟(1-2)中配置的最大樹數和最大子節點數構建由多棵樹組成的全局網絡拓撲圖，如圖1所示； (1-4)中心管理節點為全局網絡拓撲結構設定版本格式、初始版本號以及遞增方式,并將該全局網絡拓撲結構分發給所有樹的根成員節點，再有根成員節點分發給它的子孫成員節點。
3.根據權利要求1所述的分布式協調服務管理方法，其特征在于，編號為nodel的節點即為中心管理節點，其它節點為成員節點。
4.根據權利要求1所述的分布式協調服務管理方法，其特征在于，步驟(1-3)中全局網絡拓撲的構建過程遵循以下原則: (1-3-1)相同顏色的節點集中在一棵樹的根節點或中間節點，且分散在其它樹的葉子節點中； (1-3-2 ) —個節點可以同時出現在多棵樹中，但每個節點只能在一棵樹中充當根節點或者中間節點； (1-3-3)新節點應該插入到與之同顏色的樹中最靠近根節點的節點中，且該節點中子節點的數目未超過最大子節點數； (1-3-4) —個節點的子節點數目達到最大子節點數時，新插入的節點應該插入到該節點的子樹中，并且被插入的子樹是所有子樹中高度最矮或者子孫節點數目最少的； (1-3-5)當全局網絡拓撲結構中樹的總數達到最大樹數時，如果再有新節點加入分布式集群，則不為該新節點創 建新的樹結構，而是將該新節點插入已有的樹結構中。
5.根據權利要求1所述的分布式協調服務管理方法，其特征在于，步驟(3)中，成員節點與其他某個成員節點的心跳機制突然中斷時，表明該成員節點收到了成員減少的成員狀態變更信息，成員節點收到了它所維護的全局網絡拓撲結構中不存在的新的成員節點的心跳信息時，表明該成員節點收到了成員增加的成員狀態變更信息。
6.根據權利要求1所述的分布式協調服務管理方法，其特征在于，步驟(5)中，如果中心管理節點同時接收到來自一個以上成員節點的成員狀態變更信息，則表示成員狀態變更信息是正確的，如果僅接收到來自一個成員節點的成員狀態變更信息，則表示成員狀態變更息是錯誤的。
【文檔編號】H04L12/753GK103780497SQ201310749438
【公開日】2014年5月7日 申請日期:2013年12月30日 優先權日:2013年12月30日
【發明者】石宣化, 金海 , 吳松, 王秋月, 林浩泓, 陸路 申請人:華中科技大學