專利名稱：高速實時數據庫的智能化動態(tài)負載均衡方法
技術領域：
本發(fā)明涉及一種服務器動態(tài)負載均衡方法，具體來說涉及一種高速實時數據庫的智能化動態(tài)負載均衡方法。
背景技術：
目前，實時/歷史數據庫系統(tǒng)的部署技術中，無一例外都采用了傳統(tǒng)雙機熱備的傳統(tǒng)集群方式兩臺服務器主機共享一個物理存儲設備，兩臺主機之間通過心跳信號來決定誰將成為“主機”，誰將成為“備機”。同一時刻，只有其中一臺主機可以成為“主機”并接管共享的陣列資源。也就是說，傳統(tǒng)實時/歷史數據庫系統(tǒng)的雙機熱備技術中同時只有一臺服務器主機在提供服務，其余另外一臺是閑置的，當且僅當當前“主機”故障時，另外一臺服務器才會進行實際的工作負擔。如此以來導致的一個問題就是大多數情況下即便兩臺服務器都無故障，也只能發(fā)揮其中一臺的業(yè)務處理能力而另外一臺閑置，本發(fā)明將重點解決這個難題。現(xiàn)有的技術的缺點主要體現(xiàn)在1.不能充分利用多臺服務器的資源優(yōu)勢，大多數情況下昂貴的服務器資源是閑置的2.在單機故障時，需要切換和控制權交替的資源數量龐大，造成業(yè)務阻塞時間相對較長3.由于現(xiàn)行技術中的“非A即B”模型，造成對于業(yè)務負載邏輯的管理靈活性很差， 無法有機地將資源、負載和需求整合到一起，部署更為高階的技術方案4.現(xiàn)有一些技術通過網絡消息轉發(fā)的方式來實現(xiàn)負載的分配，雖然一定程度上達到了負載分擔的目地，但是多次的網絡轉發(fā)不僅造成了對網絡帶寬的極大浪費，而且由于轉發(fā)所引起的性能降低非常明顯。

發(fā)明內容
本發(fā)明的目的在于提供一種高速實時數據庫的智能化動態(tài)負載均衡方法，本方法能夠實現(xiàn)將多臺服務器有機地整合在一起，形成一個服務器集群網絡，并共享一個磁盤存儲設備，各個服務都正常工作的情況下各自對外提供既定的業(yè)務處理負載，本方法靈活地整合了多個服務器節(jié)點的硬軟件資源，達到硬件平臺資源利用調度最優(yōu)化。本發(fā)明的目的可通過以下的技術措施來實現(xiàn)一種高速實時數據庫的智能化動態(tài)負載均衡方法，包括如下步驟1)、在每個客戶端中配置內容一致的客戶端集群仲裁表，內容包括所有客戶端統(tǒng)一使用的一個全局的虛擬IP地址；各個集群服務器節(jié)點的物理信息集群服務器節(jié)點的物理IP地址、監(jiān)聽端口 ；各個集群服務器節(jié)點的邏輯信息各集群服務器節(jié)點可處理的任務的標簽范圍；各個集群服務器節(jié)點的接替節(jié)點當前集群服務器節(jié)點故障時，接替處理任務的集群服務器節(jié)點號；各個集群服務器節(jié)點對于各個任務的優(yōu)先級列表；2)、在每個集群服務器節(jié)點中配置內容一致的服務器端集群仲裁表，內容包括各個集群服務器節(jié)點的物理信息集群服務器節(jié)點的物理IP地址、監(jiān)聽端口 ；各個集群服務器節(jié)點的邏輯信息各集群服務器節(jié)點可處理的任務的標簽范圍；各個集群服務器節(jié)點的接替節(jié)點當前集群服務器節(jié)點故障時，接替處理任務的集群服務器節(jié)點號；各個集群服務器節(jié)點間的心跳超時間隔、集群服務器節(jié)點間的TCP發(fā)送和接收超時間隔、通訊失敗重試次數；各個集群服務器節(jié)點對于各個任務的優(yōu)先級列表；3)、將后臺數據存儲模塊劃分為不同的物理存儲分區(qū)，各個集群服務器節(jié)點對應其中一個物理存儲分區(qū)；4)、將客戶端與每個集群服務器節(jié)點建立通訊連接；并不斷從可用的集群服務器節(jié)點上同步服務器端集群仲裁表的相應內容到客戶端集群仲裁表中，用于保證客戶端集群仲裁表和服務器端集群仲裁表中相應內容始終保持一致；5)、各個集群服務器節(jié)點開始主控控制過程，用于維護各個集群服務器節(jié)點上的服務器端集群仲裁表內容一致；6)、各個集群服務器節(jié)點開始負載配置過程，用于接收并處理客戶端發(fā)送過來的任務，如果某個集群服務器節(jié)點出現(xiàn)故障，則根據服務器端集群仲裁表中的內容，將任務轉發(fā)到下一個正常服務器上處理該任務；7)、客戶端對全局的虛擬IP地址發(fā)起數據讀寫的請求，該請求中包含該讀寫操作任務的標簽，并根據所述客戶端集群仲裁表來判斷當前的任務應該被最終發(fā)往哪個目標集群服務器節(jié)點；8)、網絡通訊管理模塊根據請求的類型和請求的數據將當前請求組成一個TCP數據包，在前后加入CRC校驗信息以確保數據包的完整性；并與目標集群服務器節(jié)點模塊建立TCP連接，并最終發(fā)送往目地集群服務器節(jié)點；9)、目標集群服務器節(jié)點在接收到客戶端提交來的請求后，進行必要的校驗，然后對合法的請求進行處理，并對后臺數據存儲模塊中對應的物理存儲分區(qū)進行讀寫訪問，丟棄非法的請求并將錯誤信息回復給客戶端。所述步驟幻中集群服務器節(jié)點的主控控制流程的具體過程是5a)首先從當前集群服務器節(jié)點中讀取自身的配置信息，用于構成當前集群服務器節(jié)點的服務器端集群仲裁表。5b)啟動心跳接受線程為每一個集群服務器節(jié)點提供一個單獨的線程來接收其他集群服務器節(jié)點的心跳狀態(tài)；啟動狀態(tài)發(fā)布線程為每一個集群服務器節(jié)點提供一個單獨的線程將當前集群服務器節(jié)點的狀態(tài)定時地發(fā)給集群服務器組中其它集群服務器節(jié)點；各個集群服務器節(jié)點根據心跳接收線程和狀態(tài)發(fā)布線程實時地將檢測到的其他集群服務器節(jié)點的狀態(tài)更新各自的服務端集群仲裁表，以使各個服務端集群仲裁表內容一致。
所述步驟6)中的負載配置過程的具體步驟如下6a)、各個集群服務器節(jié)點定時地輪詢服務端集群仲裁表，如果發(fā)現(xiàn)服務器端集群仲裁表發(fā)生變化并表明其中有某個節(jié)點不可用時，進入下一步處理；或者，任何時刻，當檢測到某個遠端集群服務器節(jié)點不可用時，也進入下一步處理；6b)、對不可用的集群服務器節(jié)點上的任務進行轉移根據優(yōu)先級列表的內容，將該故障的集群服務器節(jié)點上的所有任務轉移到各個任務所對應的最高優(yōu)先級次級的集群服務器節(jié)點上；任務轉移成功后，回到步驟6a)。所述步驟6b)中將任務轉移的具體過程如下bl)、對于不可用的集群服務器節(jié)點上的每一個任務，檢查當前集群服務器節(jié)點是不是除故障節(jié)點外，最高優(yōu)先級最高的集群服務器節(jié)點，如果不是，結束本流程；否則，進入下一步；b2)、對于當前任務，發(fā)送“請求轉換”的信息給其他各個集群服務器節(jié)點；b3)、如果在集群服務器節(jié)點間的心跳接收線程的超時間隔內沒有收到某個其它的集群服務器節(jié)點對該“請求轉換”信號的確認回復，結束本流程；否則，進入下一步驟；b4)、在服務器端集群仲裁表中將檢測到的故障的集群服務器節(jié)點狀態(tài)標記為不可用，并更改相應的優(yōu)先級列表中能夠處理該任務的各個集群服務器節(jié)點的新的優(yōu)先級， 最后，在當前集群服務器節(jié)點上啟動相應操作來處理所述的轉移的任務，最后，將“轉化成功”的結果發(fā)布給其它節(jié)點。所述步驟2、和步驟幻中，各個集群服務器節(jié)點對于各個任務的優(yōu)先級列表具體形式為對于某一個任務j，l < j <M，M為集群服務器節(jié)點可處理的任務的總個數，編號為 i的集群服務器節(jié)點對于任務j具有最高的優(yōu)先級1，1 < i < N，N為集群服務器節(jié)點的總個數；編號i+Ι的集群服務器節(jié)點對于這個任務的優(yōu)先級加1，即優(yōu)先級為2，依次類推，一直編排完全部的集群服務器節(jié)點，且編號為i_l的集群服務器節(jié)點對于任務j的優(yōu)先級最低，最低優(yōu)先級為N ；對于任務j+Ι，集群服務器節(jié)點i+Ι的優(yōu)先級為1，依次類推。所述步驟6a)輪詢服務器端集群仲裁表的時間間隔為100毫秒。所述步驟6a)中檢測到某個遠端集群服務器節(jié)點不可用的方式是對某一個遠端集群服務器節(jié)點的心跳接收失??；或者，向遠端集群服務器節(jié)點的狀態(tài)發(fā)布失敗。所述步驟8)中網絡通訊管理模塊還處理由于網絡故障的超時重發(fā)以及在所有集群節(jié)點故障宕機時的本地磁盤文件緩存功能，在網絡恢復后，再將本地磁盤文件恢復到遠程集群服務器節(jié)點，以保證任何情況下數據都不會丟失。所述步驟7)中客戶端請求處理過程中如果請求執(zhí)行失敗了，錯誤結果會被回復到客戶端，客戶端根據錯誤的信息進行進一步的處理，具體過程是如果失敗的原因是因為在處理的過程中先前的集群服務器節(jié)點故障，則根據客戶端集群仲裁表做出決策，決定當前請求應該被重發(fā)到哪一個作為接替節(jié)點的集群服務器節(jié)點上；如果接替節(jié)點不能處理， 再尋找下一個接替節(jié)點，依次類推，如果經過一定的超時處理重試后，所有的服務器節(jié)點都不可用，那么報告這個請求最終執(zhí)行失敗。本發(fā)明對比現(xiàn)有技術，有如下優(yōu)點1、本方法實現(xiàn)了在正常多臺服務器都正常工作的情況下，各自都對外提供既定的業(yè)務處理負載，充分利用了昂貴的服務器資源。與此同時，由于本發(fā)明的方案中業(yè)務負載分
7布在多個服務器之上，因此在故障切換和資源控制權交替的時候需要進行交替的資源數量減少，最大限度地降低了業(yè)務阻塞時間?？梢杂袡C地將服務器硬軟件資源、負載和業(yè)務需求有機地整合在一起，進行靈活的分發(fā)和部署以進行更為高階的技術部署方案，和當前新進的“云計算”方向相得益彰；2、本方法不僅徹底解決傳統(tǒng)技術模型的局限性，而且還將服務器節(jié)點擴展到N(N >=2)節(jié)點(現(xiàn)行技術中是2個節(jié)點)，靈活地整合了 N個節(jié)點的硬軟件資源，達到硬件平臺資源利用調度最優(yōu)化，形成真正意義上的“N-N集群”技術。相比傳統(tǒng)的應用模型，在同樣的硬件環(huán)境中軟件的處理能力將提升到約N-I倍以上。本發(fā)明徹底解決了實時/歷史數據庫系統(tǒng)中的“動態(tài)負載均衡”難題，借助于本發(fā)明的技術，多臺計算機資源可以被靈活地整合在一起，形成一個性能強勁的服務集群組，而對用戶層而言，所有的這些服務器群組都是透明的；3、本方法和現(xiàn)行的虛擬IP地址技術不同的是，本發(fā)明的集群階段各自以節(jié)點的物理IP地址運行并提供服務，相比以往的一個內部往的物理地址進行數據轉發(fā)的模式相比，這種虛擬IP地址技術可以完全屏蔽以往物理虛擬IP節(jié)點導致的數據轉發(fā)延遲。不僅如此，使用物理IP地址的技術實現(xiàn)可以極大地降低內部網絡由于轉發(fā)所引起的帶寬占用。 簡而言之，這里實現(xiàn)的虛擬IP技術是一種真正意義上的虛擬IP地址，并不在內部私有網絡上實際存在，而是一個純粹的虛擬地址。每一個物理節(jié)點都配置了完全一致的集群節(jié)點IP 地址列表，列表中的IP地址先后順序就是單點故障時服務器負載轉移的優(yōu)先級和順序；4、本方法使得當集群組中所有的服務器都處于正常工作狀態(tài)時，由于各自只承擔相對小的一部分業(yè)務負載，應用的請求被處理會很高效，表現(xiàn)在響應快速并且用戶感受好； 當集群組中有一臺或者多臺服務器出現(xiàn)故障的情況下，故障節(jié)點被轉移到可以正常服務的節(jié)點上面。


圖1是本發(fā)明的高速實時數據庫的智能化動態(tài)負載均衡方法的流程圖；圖2是本發(fā)明的高速實時數據庫的智能化動態(tài)負載均衡方法中的集群軟件主控算法實現(xiàn)流程圖；圖3是本發(fā)明的高速實時數據庫的智能化動態(tài)負載均衡方法中的集群軟件仲裁算法實現(xiàn)流程圖；圖4是一個典型的集群負載配置模塊中的集群仲裁表的內容示意圖；圖5是本發(fā)明方法中各個集群服務器節(jié)點對于各個任務的優(yōu)先級列表；圖6是擁有3個節(jié)點和3個任務的優(yōu)先級列表結構。
具體實施例方式下面結合附圖對本發(fā)明做進一步的詳細說明，如圖1所示，本發(fā)明所示的智能化動態(tài)負載均衡技術包含客戶端SDK模塊(100)、網絡通訊管理模塊000)、集群服務器節(jié)點模塊(300)和后臺數據存儲模塊G00)。其中客戶端SDK模塊(100)包含集群負載配置模塊(110)和SDK通訊仲裁模塊(120)；在集群服務器節(jié)點模塊(300)中，包含服務器端集群負載配置模塊(310)、服務器端負載均衡仲裁模塊(320)和服務器端數據管理模塊(330)。
8其中服務器端數據管理模塊(330)就是傳統(tǒng)意義上的實時/歷史數據庫系統(tǒng)實例，不同的實時/歷史數據庫系統(tǒng)可能包含一個或者多個進程或者配置模塊，在本發(fā)明的系統(tǒng)實施體系中，是其中一個局部模塊。在本發(fā)明實施中，集群服務器節(jié)點模塊(300)可能包含N個，N 通常是大于等于2的服務器節(jié)點數目，不同于在現(xiàn)行實時/歷史數據庫系統(tǒng)的雙機部署技術中，N為固定為2的雙機冗余。后臺數據存儲模塊(400) —般是存儲系統(tǒng)，可以是目前主流的存儲解決方案。如圖2所示，本發(fā)明的高速實時數據庫的智能化動態(tài)負載均衡方法的完整處理步驟如下1)、首先，在每個客戶端的集群負載均衡配置模塊(110)中配置內容一致的客戶端集群仲裁表，如圖4所示，內容包括所有客戶端統(tǒng)一使用的一個全局的虛擬IP地址；各個集群服務器節(jié)點的物理信息集群服務器節(jié)點的物理IP地址、監(jiān)聽端口 ；(以下將“集群服務器節(jié)點”簡稱為“節(jié)點”。)各個集群服務器節(jié)點的邏輯信息各集群服務器節(jié)點可處理的任務的標簽范圍；各個集群服務器節(jié)點的接替節(jié)點當前集群服務器節(jié)點故障時，接替處理任務的集群服務器節(jié)點號；各個集群服務器節(jié)點對于各個任務的優(yōu)先級列表；2)、在每個集群服務器節(jié)點的集群負載配置模塊(310)中配置內容一致的服務器端集群仲裁表，內容包括各個集群服務器節(jié)點的物理信息集群服務器節(jié)點的物理IP地址、監(jiān)聽端口 ；各個集群服務器節(jié)點的邏輯信息各集群服務器節(jié)點可處理的任務的標簽范圍；各個集群服務器節(jié)點的接替節(jié)點當前集群服務器節(jié)點故障時，接替處理任務的集群服務器節(jié)點號；各個集群服務器節(jié)點間的心跳超時間隔、集群服務器節(jié)點間的TCP發(fā)送和接收超時間隔、通訊失敗重試次數；服務器端集群負載配置模塊(310)和客戶端集群負載配置模塊(110)作用是完全一樣的，只不過服務器端集群負載配置模塊(310)還包含心跳接收超時設置等其它參數。各個集群服務器節(jié)點對于各個任務的優(yōu)先級列表；具體形式如圖5所示對于某一個任務j，1 < j < M，M為集群服務器節(jié)點可處理的任務的總個數，編號為i的集群服務器節(jié)點對于任務j具有最高的優(yōu)先級1，1 < i < N，N為集群服務器節(jié)點的總個數；編號i+1 的集群服務器節(jié)點對于這個任務的優(yōu)先級加1，即優(yōu)先級為2，依次類推，一直編排完全部的集群服務器節(jié)點，且編號為i_l的集群服務器節(jié)點對于任務j的優(yōu)先級最低，最低優(yōu)先級為N ；對于任務j+Ι，集群服務器節(jié)點i+Ι的優(yōu)先級為1，依次類推。從而得到一個從高到底的優(yōu)先級列表，并將優(yōu)先級列表中的信息加入客戶端集群仲裁表中；客戶端集群仲裁表包含每一個服務器節(jié)點的狀態(tài)和每一個任務在各個服務器節(jié)點上的優(yōu)先級；如圖5所示。3)、將后臺數據存儲模塊(400)劃分為不同的物理存儲分區(qū)，各個集群服務器節(jié)點對應其中一個物理存儲分區(qū)；(不同的物理存儲分區(qū)具體是和集群服務器節(jié)點的數據管理模塊(330)—對一對應的，當一個集群服務器節(jié)點的數據管理模塊(330)從一個物理計算機轉移到另外一個計算機的時候，這種對應關系不變。所有集群服務器節(jié)點的數據管理模塊(330)啟動后就如運行在一臺獨立服務器上面一樣，接收SDK端的發(fā)起的請求并統(tǒng)一訪問后臺數據存儲模塊 (400)以及進行相應的處理。)4)、將客戶端與每個集群服務器節(jié)點建立通訊連接；并不斷從可用的集群服務器節(jié)點上同步服務器端集群仲裁表的相應內容到客戶端集群仲裁表中，用于保證客戶端集群仲裁表和服務器端集群仲裁表中相應內容始終保持一致；(SDK通訊仲裁模塊(120)根據服務器集群仲裁表來維護客戶端集群仲裁表，客戶端集群仲裁表和服務器端集群仲裁表是一致統(tǒng)一的，內容是相同的；工作循環(huán)SDK通訊仲裁模塊(120)和每一個集群服務器節(jié)點建立連接，根據客戶端的集群負載均衡配置模塊 (110)中確立的優(yōu)先級，始終從優(yōu)先級最高的可用節(jié)點上同步服務器集群仲裁表到客戶端集群仲裁表，因為服務器集群仲裁表由服務器端的負載均衡仲裁模塊(320)同步和管理， 保證客戶端的這種工作方式的正確性。當SDK通訊仲裁模塊(120)檢測到某些服務器集群節(jié)點故障而導致的連接中斷時，SDK通訊仲裁模塊(120)會嘗試重現(xiàn)建立連接，因此一旦有服務器節(jié)點故障又恢復后，SDK通訊仲裁模塊(120)都會第一時間刷新到最新狀態(tài)。)5)、各個集群服務器節(jié)點的負載均衡仲裁模塊(320)開始主控控制過程，用于維護各個集群服務器節(jié)點上的服務器端集群仲裁表內容一致，如圖3所示，具體過程是fe)、首先從當前集群服務器節(jié)點中讀取自身的配置信息，用于構成當前集群服務器節(jié)點的服務器端集群仲裁表。(在本發(fā)明的中，要求集群組中的各個節(jié)點的IP和負載設置參數完全一致，否則在后續(xù)的切換和負載交互的過程中可能出現(xiàn)沖突。)5b)、啟動心跳接受線程為每一個集群服務器節(jié)點提供一個單獨的線程來接收其他集群服務器節(jié)點的心跳狀態(tài)；一個群集服務器節(jié)點在接收到一個來自其它節(jié)點的心跳狀態(tài)后，如果接收到心跳的時間沒有超過服務器集群負載配置模塊(310)中設置的心跳接收超時間隔，則更新當前節(jié)點的集群仲裁表，標記發(fā)動端節(jié)點狀態(tài)為可用，同時記錄接收到心跳的時間；相反，如果在設置的心跳接收超時間隔內沒有收到某個節(jié)點的心跳，則認為這個遠端節(jié)點發(fā)生了故障，并標記該遠端節(jié)點為不可用。(這里啟動線程的數據和集群組中配置的節(jié)點數目一致，每一個節(jié)點通過單獨的線程來進行心跳接受。這樣設計的目的是為了避免單個節(jié)點網絡故障或者其它主機故障而導致心跳的實時性。因此單點的故障完全不影響其它節(jié)點并且可以被其它節(jié)點實時準確地檢測到。)啟動狀態(tài)發(fā)布線程為每一個集群服務器節(jié)點提供一個單獨的線程將當前集群服務器節(jié)點的狀態(tài)定時地發(fā)給集群服務器組中其它集群服務器節(jié)點；各個集群服務器節(jié)點根據心跳接收線程和狀態(tài)發(fā)布線程實時地將檢測到的其他集群服務器節(jié)點的狀態(tài)更新各自的服務端集群仲裁表，以使各個服務端集群仲裁表內容一致；(狀態(tài)發(fā)布線程用以確保其它節(jié)點可以實時地同步到集群組中其它節(jié)點去。和心跳接收部分的策略一樣，狀態(tài)發(fā)送部分也是為每一個集群服務器節(jié)點提供一個單獨的線程來進行狀態(tài)發(fā)布，其主要的原因也是為了避免單點的網絡故障、延時或者其它故障導致心跳的實時性問題。值得注意的是，雖然在主控算法中引入了集群組中節(jié)點數目兩倍的線程數，但是這些線程都是輕量級的，大多數時間都是在等待觸發(fā)或者發(fā)送流量很小的心跳或者狀態(tài)信息幀，因此對節(jié)點主機、整理集群組網絡等都不會造成資源競爭問題。)
10
6)、各個集群服務器節(jié)點的負載配置模塊(310)開始負載配置過程，用于接收并處理客戶端發(fā)送過來的任務，如果某個集群服務器節(jié)點出現(xiàn)故障，則根據服務器端集群仲裁表中的內容，將任務轉發(fā)到下一個正常服務器上處理該任務，負載配置具體過程如下6a)、服務器端負載均衡仲裁模塊(320)定時地輪詢服務端集群仲裁表，如果發(fā)現(xiàn)服務器端集群仲裁表發(fā)生變化并表明其中有某個節(jié)點不可用時，進入下一步處理；或者，任何時刻，當檢測到某個遠端集群服務器節(jié)點不可用時，也進入下一步處理；否則，重復步驟 6a)；所述輪詢服務器端集群仲裁表的時間間隔為100毫秒；其中，檢測到某個遠端集群服務器節(jié)點不可用的方式是對某一個遠端集群服務器節(jié)點的心跳接收失??；或者，向遠端集群服務器節(jié)點模塊(300)狀態(tài)發(fā)布失敗。緊急事件發(fā)生的含義也就是當狀態(tài)發(fā)布線程檢測到發(fā)往某一個集群節(jié)點的動作執(zhí)行失敗，通常意味著對端節(jié)點故障。對于這個故障檢測，另一方面是通過“心跳接收”來被動檢測到某個節(jié)點不可用了，是雙向的，一方面是通過“狀態(tài)發(fā)布”線程來主動檢測到某個節(jié)點不可用了 ；因為實際存在一些網絡或者硬件原因，一個方向的信息是暢通的，而相反的方向是阻塞的，遇到這樣的情況會導致仲裁表更新不準確或者延時，從而使得狀態(tài)檢測更加可靠嚴謹。輪詢的目地是周期性地查看服務端集群仲裁表是否發(fā)生變化，如果有變化，根據這個變化去決定是否要做一些操作來應對這個變化。比如對于某個任務，優(yōu)先級第一的節(jié)點故障了，那么標記該集群服務器節(jié)點“不可用”，同時，按照優(yōu)先級列表，該任務由優(yōu)先級次一級的集群服務器節(jié)點來處理，具體判斷和的處理過程如下如果檢測到有緊急事件，首先還是會改變服務器集群仲裁表，因為緊急事件肯定是有狀態(tài)發(fā)布線程或者心跳接收線程發(fā)起的，當檢測到緊急事件時，無論狀態(tài)發(fā)布線程還是心跳接收線程，首先都是根據緊急事件是發(fā)生在和哪一個節(jié)點的通訊過程中，然后將相應節(jié)點對應的狀態(tài)改為不可用(這一點先前可能說得不清楚)，輪詢的動作只根據服務器集群仲裁表的情況執(zhí)行相應的動作，有變化繼續(xù)執(zhí)行步驟c，無變化就回到步驟a ；另外，輪詢檢查的目地是因為現(xiàn)在有狀態(tài)發(fā)布和心跳接收兩個方向的通訊，心跳接收線程除了將接收到其它節(jié)點的心跳后，認為這個發(fā)送節(jié)點可用的同時，還會將接收到心跳的時間記錄下來；但是在某些情況下，比如網絡路由器故障等，會出現(xiàn)這兩個方向的通訊阻塞而沒有返回，因此當前輪詢的節(jié)點是要避免這種情況，通過設置在服務器集群負載配置模塊(310) 中的心跳接收超時間隔來確保服務端仲裁表的準確性。請結合步驟二的補充整理一下)，并回到步驟6a)；否則，進入下一步驟；6b)、對不可用的集群服務器節(jié)點上的任務進行轉移根據優(yōu)先級列表的內容，將該故障的集群服務器節(jié)點上的所有任務轉移到各個任務所對應的最高優(yōu)先級次級的集群服務器節(jié)點上。由于不可用的集群服務器節(jié)點，即表明該節(jié)點發(fā)生故障無法正常處理各種， 需要將該故障節(jié)點上的所有任務都轉移到其他正常的集群服務器節(jié)點上，因此需要進行任務的轉移。這個檢查過程是各個集群服務器節(jié)點都在并行地進行，但是針對同一個范圍內的標簽對應的處理負載任務，各個節(jié)點的優(yōu)先級是不一樣的。任務轉移結束后，回到步驟 6a) ο步驟6b)的任務進行轉移的具體過程如下
bl)、對于不可用的集群服務器節(jié)點上的每一個任務，檢查當前集群服務器節(jié)點是不是最高優(yōu)先級次級的集群服務器節(jié)點，如果不是，回到步驟a ；否則，進入下一步；b2)、對于當前任務，發(fā)送“請求轉換”的信息給其他各個集群服務器節(jié)點；(發(fā)送這個“請求轉換”是告訴其它節(jié)點，已經有一個優(yōu)先級較高的活動節(jié)點在處理這個任務了， 其它節(jié)點不需要針對這個事件做任何動作了)；b3)、如果在集群服務器節(jié)點間的心跳接收線程的超時間隔內沒有收到某個其它的集群服務器節(jié)點對該“請求轉換”信號的確認回復，則回到步驟a;否則，進入下一步驟； 因為，確立為優(yōu)先級最高的節(jié)點Nodel，在向其他節(jié)點(Nodd-NodeN)等待確認“請求轉換” 信號的時候，如果其中一個節(jié)點NodeX(2 < X < N)又發(fā)生故障了，因此無法對當前節(jié)點的 “請求轉換”信息進行回復，而這個節(jié)點X的故障可能會導致優(yōu)先級列表發(fā)生新的變化，因此，這個時候要重新來開始負載配置過程，即可重新根據優(yōu)先級列表重新進行任務的轉移操作。b4)、在服務器端集群仲裁表中將檢測到的故障的集群服務器節(jié)點狀態(tài)標記為不可用，并更改相應的優(yōu)先級列表中能夠處理該任務的各個集群服務器節(jié)點的新的優(yōu)先級， 最后，在當前集群服務器節(jié)點上啟動相應操作來處理所述的轉移的任務，最后，將“轉化成功”的結果發(fā)布給其它節(jié)點。由于每一個集群服務器節(jié)點都在進行負載配置過程，因此，總有一個優(yōu)先級最高的節(jié)點來接替并處理需要轉移的任務。舉一個比較簡單的例子來說明一個仲裁和任務的優(yōu)先級處理邏輯如圖6所示的優(yōu)先級列表，在最簡單有3個服務器節(jié)點，也只有3個任務的情況下，那么默認情況下Taskl在Nodel上有最高的優(yōu)先級，Task2在Node2上有最高的優(yōu)先級，Task3在Node3上有最高的優(yōu)先級；如果Node3故障，那么Task3由于有用最高固定優(yōu)先級的節(jié)點故障，其最高可用優(yōu)先級為Nodel上面的優(yōu)先級2，因此Task3應該被Nodel啟動起來。在上面的情況中，Node3故障，Nodel和Node2都會檢測到，Nodel檢測到Node3故障后，根據N0del/N0de2/N0de3都完全一致的仲裁表和任務優(yōu)先級表，Nodel可以判斷出自己成為Task3最高的可用優(yōu)先級節(jié)點，因此Nodel向Node2發(fā)送“請求轉換”的消息，Node2回復后開始執(zhí)行啟動Task3 ；如果沒有收到Node2的回復，說明Node2故障了 ；這種情況下就不繼續(xù)下面的流程了，而是回到第一步，根據最新的仲裁表執(zhí)行流程；因為Node2故障意味著Task2的最高可用優(yōu)先級幾點也變成Nodel 了(Node3已經故障了)。這種情況下Taskl/ Task2/Task3都會被啟動在Nodel上面。實際應用中，同一個節(jié)點上可能有多個任務Task和節(jié)點Node。各個節(jié)點都在發(fā)布狀態(tài)并接收心跳，以及超時輪詢操作。任何一個Node的故障其它節(jié)點都會檢測到，只是由于任務分布優(yōu)先級的不一樣，各個節(jié)點要做的動作是不一樣的，而任何一個節(jié)點在執(zhí)行動作的過程中，相對于自己的其它節(jié)點還可能有故障了。5)、客戶端的SDK模塊(100)對全局的虛擬IP地址發(fā)起數據讀寫的請求，該請求中包含該讀寫操作任務的標簽，所述請求由SDK通訊仲裁模塊(120)根據集群負載配置模塊(110)的客戶端集群仲裁表來判斷當前的任務應該被最終發(fā)往哪個目標集群服務器節(jié)占.6)、網絡通訊管理模塊(200)根據請求的類型和請求的數據(例如標簽號、開始時間和結束時間等)將當前請求組成一個TCP數據包，在前后加入CRC校驗信息以確保數據包的完整性；并與目標集群服務器節(jié)點模塊建立TCP連接，SDK通訊仲裁模塊(120)選擇已經建立到目標集群服務器節(jié)點模塊(300)的TCP連接，通過網絡通訊管理模塊(200)來管理并最終發(fā)送往目地服務器；另外網絡通訊管理模塊(200)還處理由于網絡故障的超時重發(fā)以及在所有集群節(jié)點故障宕機時的本地磁盤文件緩存功能，在網絡恢復后，再將本地磁盤文件恢復到遠程集群服務器節(jié)點，以保證任何情況下數據都不會丟失。步驟6)的發(fā)送過程中，如果目標集群服務器節(jié)點由于硬軟件故障等原因當前不可用，那么SDK通訊仲裁模塊(120)會按照客戶端集群仲裁表中的信息來查找下一個可用的集群服務器節(jié)點，直到找到一個正常可用的集群服務器節(jié)點；最終將這個請求提交到正確并工作正常的集群服務器節(jié)點上面去；7)、目標集群服務器節(jié)點的數據管理模塊(330)在接收到客戶端提交來的請求后，進行必要的校驗，然后對合法的請求進行處理，并對后臺數據存儲模塊G00)中對應的物理存儲分區(qū)進行讀寫訪問，丟棄非法的請求并將錯誤信息回復給客戶端。請求處理過程中如果請求執(zhí)行失敗了，錯誤結果會被回復到客戶端，客戶端根據錯誤的信息進行進一步的處理，具體過程是如果失敗的原因是因為在處理的過程中先前的集群服務器節(jié)點故障(宕機、斷電或者OS異常等)，SDK通訊仲裁模塊(120)將根據客戶端集群仲裁表做出決策，決定當前請求應該被重發(fā)到哪一個作為接替節(jié)點的集群服務器節(jié)點上。如果接替節(jié)點不能處理，再尋找下一個接替節(jié)點，依次類推，如果經過一定的超時處理重試后，所有的服務器節(jié)點都不可用，那么報告這個請求最終執(zhí)行失敗。通常這是一種極端異常的請求，是嚴重的事故。本發(fā)明的內容主要包含實時/歷史數據庫系統(tǒng)服務器端的負載均衡模塊和應用程序開發(fā)端SDK內部負載均衡模塊。對于SDK端的負載均衡模塊，現(xiàn)行技術中的實現(xiàn)一般是配置一個虛擬的IP地址，不論后臺集群服務器各個節(jié)點的狀態(tài)如何，對應客戶端都是透明的，SDK端的接口都是針對這個唯一的虛擬IP地址里進行數據的寫入和查詢操作。而本發(fā)明的中SDK端的實現(xiàn)是基于一個和服務器集群端配置內容一樣的集群節(jié)點物理IP地址列表，其中可以包含N(N>= 2)個物理IP地址，本發(fā)明的實現(xiàn)將客戶端SDK對該物理IP 地址列表實現(xiàn)封裝成一個統(tǒng)一的模塊。對于傳統(tǒng)的集群部署方式或者其它地方系統(tǒng)，可以在不修改應用邏輯的情況下將本發(fā)明的技術集成到現(xiàn)有的應用系統(tǒng)中，當然也可以無縫地替換已經存在的其它集群解決方案。本發(fā)明SDK配置文件主要包含各個幾點的物理IP地址、節(jié)點默認承擔的負載比重和節(jié)點的參數，例如負載轉移策略、負載恢復策略等。與此同時，我們SDK內部實現(xiàn)會提供一個虛擬IP地址給用戶，這個虛擬IP可以是非常特殊的IP地址，不和網絡中的物理IP地址沖突即可，例如“99. 99. 99. 99”，因為它僅僅是一個純用戶層面的虛擬地址。SDK內部智能維護和管理“用戶- >虛擬IP- >配置映射表- >遠端集群組”的通訊邏輯，實際上因為內部維護的是當前客戶端和集群組內各個節(jié)點的點對點連接，通過這種技術實現(xiàn)的通訊方式十分高效，避免和傳統(tǒng)技術中通過網絡數據包轉發(fā)的方式引起的性能損失。本發(fā)明中服務器端的負載均衡模塊的實現(xiàn)和傳統(tǒng)的集群實現(xiàn)方式也有很大的區(qū)別，和現(xiàn)行的虛擬IP地址技術不同的是，本發(fā)明的集群階段各自以節(jié)點的物理IP地址運行并提供服務，相比以往的一個內部往的物理地址進行數據轉發(fā)的模式相比，這種虛擬IP地址技術可以完全屏蔽以往物理虛擬IP節(jié)點導致的數據轉發(fā)延遲。不僅如此，使用物理IP 地址的技術實現(xiàn)可以極大地降低內部網絡由于轉發(fā)所引起的帶寬占用。簡而言之，這里實現(xiàn)的虛擬IP技術是一種真正意義上的虛擬IP地址，并不在內部私有網絡上實際存在，而是一個純粹的虛擬地址。虛擬IP地址的技術實現(xiàn)需要結合用戶層的統(tǒng)一訪問技術實現(xiàn)所闡述的技術細節(jié)來實現(xiàn)，在這里我們只闡述內部節(jié)點的同步轉移機制。每一個物理節(jié)點都配置了完全一致的集群節(jié)點IP地址列表，列表中的IP地址先后順序就是單點故障時服務器負載轉移的優(yōu)先級和順序。本發(fā)明可以將多臺服務器有機地整合在一起，形成一個服務器集群網絡，各個服務器節(jié)點通過內部私有網絡連接起來，內部的私有網絡一般是千兆高速網絡。這個服務器集群組共享一個磁盤存儲設備，集群組內的任何一臺服務器都可以訪問這個共享的磁盤存儲設備。在集群組內部的各個服務器節(jié)點上，運行本發(fā)明設計中的實時通訊軟件，用于各個節(jié)點間必要信息的實時同步和分發(fā)同步緩存數據。實時通訊軟件將整個集群組有機地組織在一起，對外提供一個統(tǒng)一的IP地址，任何時候上層應用和最終用戶只需要向這個統(tǒng)一的 IP地址發(fā)起請求即可。只有集群組里面有一臺服務器能夠提供正常的對外服務，其它應用都可以在不間斷業(yè)務的情況進行日常工作，對應用軟件來說是完全透明的，只不過唯一的差別在于當集群組中所有的服務器都處于正常工作狀態(tài)時，由于各自只承擔相對小的一部分業(yè)務負載，應用的請求被處理會很高效，表現(xiàn)在響應快速并且用戶感受好；當集群組中有一臺或者多臺服務器出現(xiàn)故障的情況下，故障節(jié)點被轉移到可以正常服務的節(jié)點上面， 導致優(yōu)先的可用服務節(jié)點的負載率較高，極端情況下可能會對上層應用造成延遲。但是這個情況是客觀存在且不可避免的，因為最極端的負載率情況和傳統(tǒng)現(xiàn)行技術實現(xiàn)是完全等同的。本發(fā)明所述的實時/歷史數據庫系統(tǒng)的智能化負載均衡技術應用于流程行業(yè)需要7* 小時穩(wěn)定運行的數據庫服務器系統(tǒng)上，也可以應用于任何有負載均衡需求同時不想引入其它復雜的第三方硬軟件模塊的系統(tǒng)中。本發(fā)明的實施方式不限于此，在本發(fā)明上述基本技術思想前提下，按照本領域的普通技術知識和慣用手段對本發(fā)明內容所做出其它多種形式的修改、替換或變更，均落在本發(fā)明權利保護范圍之內。
權利要求
1.一種高速實時數據庫的智能化動態(tài)負載均衡方法，包括如下步驟1)、在每個客戶端中配置內容一致的客戶端集群仲裁表，內容包括 所有客戶端統(tǒng)一使用的一個全局的虛擬IP地址；各個集群服務器節(jié)點的物理信息集群服務器節(jié)點的物理IP地址、監(jiān)聽端口 ； 各個集群服務器節(jié)點的邏輯信息各集群服務器節(jié)點可處理的任務的標簽范圍； 各個集群服務器節(jié)點的接替節(jié)點當前集群服務器節(jié)點故障時，接替處理任務的集群服務器節(jié)點號；各個集群服務器節(jié)點對于各個任務的優(yōu)先級列表；2)、在每個集群服務器節(jié)點中配置內容一致的服務器端集群仲裁表，內容包括 各個集群服務器節(jié)點的物理信息集群服務器節(jié)點的物理IP地址、監(jiān)聽端口 ； 各個集群服務器節(jié)點的邏輯信息各集群服務器節(jié)點可處理的任務的標簽范圍； 各個集群服務器節(jié)點的接替節(jié)點當前集群服務器節(jié)點故障時，接替處理任務的集群服務器節(jié)點號；各個集群服務器節(jié)點間的心跳超時間隔、集群服務器節(jié)點間的TCP發(fā)送和接收超時間隔、通訊失敗重試次數；各個集群服務器節(jié)點對于各個任務的優(yōu)先級列表；3)、將后臺數據存儲模塊劃分為不同的物理存儲分區(qū)，各個集群服務器節(jié)點對應其中一個物理存儲分區(qū)；4)、將客戶端與每個集群服務器節(jié)點建立通訊連接；并不斷從可用的集群服務器節(jié)點上同步服務器端集群仲裁表的相應內容到客戶端集群仲裁表中，用于保證客戶端集群仲裁表和服務器端集群仲裁表中相應內容始終保持一致；5)、各個集群服務器節(jié)點開始主控控制過程，用于維護各個集群服務器節(jié)點上的服務器端集群仲裁表內容一致；6)、各個集群服務器節(jié)點開始負載配置過程，用于接收并處理客戶端發(fā)送過來的任務， 如果某個集群服務器節(jié)點出現(xiàn)故障，則根據服務器端集群仲裁表中的內容，將任務轉發(fā)到下一個正常服務器上處理該任務；7)、客戶端對全局的虛擬IP地址發(fā)起數據讀寫的請求，該請求中包含該讀寫操作任務的標簽，并根據所述客戶端集群仲裁表來判斷當前的任務應該被最終發(fā)往哪個目標集群服務器節(jié)點；8)、網絡通訊管理模塊根據請求的類型和請求的數據將當前請求組成一個TCP數據包，在前后加入CRC校驗信息以確保數據包的完整性；并與目標集群服務器節(jié)點模塊建立 TCP連接，并最終發(fā)送往目地集群服務器節(jié)點；9)、目標集群服務器節(jié)點在接收到客戶端提交來的請求后，進行必要的校驗，然后對合法的請求進行處理，并對后臺數據存儲模塊中對應的物理存儲分區(qū)進行讀寫訪問，丟棄非法的請求并將錯誤信息回復給客戶端。
2.根據權利要求1所述的高速實時數據庫的智能化動態(tài)負載均衡方法，其特征在于 所述步驟幻中集群服務器節(jié)點的主控控制流程的具體過程是fe)、首先從當前集群服務器節(jié)點中讀取自身的配置信息，用于構成當前集群服務器節(jié)點的服務器端集群仲裁表；5b)、啟動心跳接受線程為每一個集群服務器節(jié)點提供一個單獨的線程來接收其他集群服務器節(jié)點的心跳狀態(tài)；啟動狀態(tài)發(fā)布線程為每一個集群服務器節(jié)點提供一個單獨的線程將當前集群服務器節(jié)點的狀態(tài)定時地發(fā)給集群服務器組中其它集群服務器節(jié)點；各個集群服務器節(jié)點根據心跳接收線程和狀態(tài)發(fā)布線程實時地將檢測到的其他集群服務器節(jié)點的狀態(tài)更新各自的服務端集群仲裁表，以使各個服務端集群仲裁表內容一致。
3.根據權利要求1所述的高速實時數據庫的智能化動態(tài)負載均衡方法，其特征在于 所述步驟6)中的負載配置過程的具體步驟如下6a)、各個集群服務器節(jié)點定時地輪詢服務端集群仲裁表，如果發(fā)現(xiàn)服務器端集群仲裁表發(fā)生變化并表明其中有某個節(jié)點不可用時，進入下一步處理；或者，任何時刻，當檢測到某個遠端集群服務器節(jié)點不可用時，也進入下一步處理；6b)、對不可用的集群服務器節(jié)點上的任務進行轉移根據優(yōu)先級列表的內容，將該故障的集群服務器節(jié)點上的所有任務轉移到各個任務所對應的最高優(yōu)先級次級的集群服務器節(jié)點上；任務轉移成功后，回到步驟6a)。
4.根據權利要求1所述的高速實時數據庫的智能化動態(tài)負載均衡方法，其特征在于 所述步驟6b)中將任務轉移的具體過程如下bl)、對于不可用的集群服務器節(jié)點上的每一個任務，檢查當前集群服務器節(jié)點是不是除故障節(jié)點外，最高優(yōu)先級最高的集群服務器節(jié)點，如果不是，結束本流程；否則，進入下一止少；b2)、對于當前任務，發(fā)送“請求轉換”的信息給其他各個集群服務器節(jié)點； b3)、如果在集群服務器節(jié)點間的心跳接收線程的超時間隔內沒有收到某個其它的集群服務器節(jié)點對該“請求轉換”信號的確認回復，結束本流程；否則，進入下一步驟；b4)、在服務器端集群仲裁表中將檢測到的故障的集群服務器節(jié)點狀態(tài)標記為不可用， 并更改相應的優(yōu)先級列表中能夠處理該任務的各個集群服務器節(jié)點的新的優(yōu)先級，最后， 在當前集群服務器節(jié)點上啟動相應操作來處理所述的轉移的任務，最后，將“轉化成功”的結果發(fā)布給其它節(jié)點。
5.根據權利要求1所述的高速實時數據庫的智能化動態(tài)負載均衡方法，其特征在于 所述步驟幻和步驟幻中，各個集群服務器節(jié)點對于各個任務的優(yōu)先級列表具體形式為對于某一個任務j，1 < j < M，M為集群服務器節(jié)點可處理的任務的總個數，編號為i的集群服務器節(jié)點對于任務i具有最高的優(yōu)先級1，1 < i < N，N為集群服務器節(jié)點的總個數；編號i+Ι的集群服務器節(jié)點對于這個任務的優(yōu)先級加1，即優(yōu)先級為2，依次類推，一直編排完全部的集群服務器節(jié)點，且編號為i_l的集群服務器節(jié)點對于任務j的優(yōu)先級最低，最低優(yōu)先級為N ；對于任務j+Ι，集群服務器節(jié)點i+Ι的優(yōu)先級為1，依次類推。
6.根據權利要求1所述的高速實時數據庫的智能化動態(tài)負載均衡方法，其特征在于 所述步驟6a)輪詢服務器端集群仲裁表的時間間隔為100毫秒。
7.根據權利要求1所述的高速實時數據庫的智能化動態(tài)負載均衡方法，其特征在于 所述步驟6a)中檢測到某個遠端集群服務器節(jié)點不可用的方式是對某一個遠端集群服務器節(jié)點的心跳接收失敗；或者，向遠端集群服務器節(jié)點的狀態(tài)發(fā)布失敗。
8.根據權利要求1所述的高速實時數據庫的智能化動態(tài)負載均衡方法，其特征在于所述步驟8)中網絡通訊管理模塊還處理由于網絡故障的超時重發(fā)以及在所有集群節(jié)點故障宕機時的本地磁盤文件緩存功能，在網絡恢復后，再將本地磁盤文件恢復到遠程集群服務器節(jié)點，以保證任何情況下數據都不會丟失。
9.根據權利要求1所述的高速實時數據庫的智能化動態(tài)負載均衡方法，其特征在于 所述步驟7)中客戶端請求處理過程中如果請求執(zhí)行失敗了，錯誤結果會被回復到客戶端， 客戶端根據錯誤的信息進行進一步的處理，具體過程是如果失敗的原因是因為在處理的過程中先前的集群服務器節(jié)點故障，則根據客戶端集群仲裁表做出決策，決定當前請求應該被重發(fā)到哪一個作為接替節(jié)點的集群服務器節(jié)點上；如果接替節(jié)點不能處理，再尋找下一個接替節(jié)點，依次類推，如果經過一定的超時處理重試后，所有的服務器節(jié)點都不可用， 那么報告這個請求最終執(zhí)行失敗。
全文摘要
本發(fā)明公開了一種高速實時數據庫的智能化動態(tài)負載均衡方法，本方法包括如下步驟在每個客戶端和集群服務器節(jié)點中配置內容一致的集群仲裁表；將后臺數據存儲模塊劃分為不同的物理存儲分區(qū)；將客戶端與每個集群服務器節(jié)點建立通訊連接；各個集群服務器節(jié)點維護各個集群服務器節(jié)點上的服務器端集群仲裁表內容一致；接收并處理客戶端發(fā)送過來的任務；客戶端對全局的虛擬IP地址發(fā)起數據讀寫的請求；網絡通訊管理模塊最終發(fā)送往目地集群服務器節(jié)點；目標集群服務器節(jié)點在接收到客戶端提交來的請求后，進行必要的校驗，然后對合法的請求進行處理。本法本方法靈活地整合了多個服務器節(jié)點的硬軟件資源，達到硬件平臺資源利用調度最優(yōu)化。
文檔編號H04L29/08GK102404390SQ20111034848
公開日2012年4月4日 申請日期2011年11月7日 優(yōu)先權日2011年11月7日
發(fā)明者周伊琳, 孫建偉, 陳揚, 陳炯聰, 黃縉華 申請人:廣東電網公司電力科學研究院