用于集群節(jié)點縮擴的方法、設備和系統(tǒng)的制作方法
【技術領域】
[0001]本發(fā)明涉及節(jié)點集群領域，具體涉及用于集群節(jié)點縮擴的方法、設備和系統(tǒng)。
【背景技術】
[0002]Redis (遠程字典服務，Remote Dict1nary Service)是一種全內(nèi)存的 Key/Value(鍵值對)緩存/存儲系統(tǒng)。由于受單個節(jié)點所在服務器內(nèi)存容量限制，在大規(guī)模數(shù)據(jù)緩存/存儲場景下，一般由多個節(jié)點組成集群，每個節(jié)點只負責存儲部分數(shù)據(jù)，稱為shardingo客戶端根據(jù)Key (鍵)和節(jié)點的映射關系，將對特定Key的請求發(fā)送到特定節(jié)點。
[0003]Key和節(jié)點的映射關系，目前常用的方式是由客戶端路由算法來實現(xiàn)。將節(jié)點按順序編號，以Key作為參數(shù)，通過一個Hash函數(shù)算出一個數(shù)值，然后根據(jù)節(jié)點的數(shù)量來取模(或者一致性Hash算法)以定位到一個節(jié)點。由于是通過算法來進行路由，算法本身也能保證路由的時間復雜度是0(1)，而且并不需要在任何地方存儲Key到節(jié)點的映射關系，因此被主要使用在有大量的、不斷增長的Key/Value的存儲場景。
[0004]但是客戶端路由算法也存在著弊端。目標節(jié)點數(shù)量和編號一旦發(fā)生變化，key和節(jié)點的映射關系就會發(fā)生變化，客戶端之前通過舊的映射關系寫入到節(jié)點A的key/value數(shù)據(jù)，由于通過新的映射關系映射到節(jié)點B，可能會去節(jié)點B上讀取而無法讀取到。因此，在由于數(shù)據(jù)量增長而需要增加節(jié)點時，必須遍歷所有key (通常直接調(diào)用redis的命令接口來執(zhí)行遍歷)，在節(jié)點間迀移數(shù)據(jù)，以便反映最新的映射關系。這種通過增加節(jié)點來增大整體集群容量的方式被稱為水平擴展。水平擴展造成的數(shù)據(jù)迀移通常會非常耗時并且很難在線進行。
[0005]為了避免節(jié)點變化造成的數(shù)據(jù)迀移。可以采取pre-sharding方案，S卩預先估計數(shù)據(jù)量及其增長速度，設定一個合適的足夠多的節(jié)點數(shù)量。而且，為了避免占有過多的物理服務器，通常初期會在同一服務器上部署多個節(jié)點，隨著數(shù)據(jù)量的增長，通過將節(jié)點迀移到新增加的物理服務器上，使得每個節(jié)點擁有更多的內(nèi)存資源，從而使得整體集群的內(nèi)存容量擴大。迀移節(jié)點到其他服務器，采取redis本身提供的主從復制實現(xiàn)即可實現(xiàn)。由于只是更改節(jié)點與物理機的映射關系，節(jié)點數(shù)量和編號并未發(fā)生變化，不需要在節(jié)點之間迀移數(shù)據(jù)。這種通過增大單節(jié)點的容量、節(jié)點數(shù)不發(fā)生變化的方式也稱為垂直擴展。
[0006]垂直擴展需要預先規(guī)劃數(shù)據(jù)容量和增長。評估合適的足夠多的節(jié)點并不容易。節(jié)點數(shù)量的設立需要綜合考慮內(nèi)存消耗和數(shù)據(jù)增長，隨著超出預計的數(shù)據(jù)增長，即使一個物理服務器部署一個節(jié)點，由于受制于物理服務器內(nèi)存而無法繼續(xù)擴展，不可避免需要水平擴展來解決整體集群的容量擴大。
[0007]而上面談到的水平擴展造成的數(shù)據(jù)迀移需要遍歷所有的key，按照新的映射關系，將數(shù)據(jù)迀移到新的節(jié)點上，這整個過程通常會非常耗時。而且也很難在線進行。
[0008]還存在離線的水平擴展方案，即:在擴展前先停止所有客戶端的讀寫，迀移完成后，再允許客戶端按照新的映射關系進行讀寫。這種離線的水平擴展避免了迀移程序和客戶端程序同時進行讀寫而造成的數(shù)據(jù)沖突和不一致性，但是需要較長的禁止讀寫時間。然而業(yè)務需求卻常常不允許長時間的禁止讀寫，因此需要一個能夠進行在線水平擴展的方案。

【發(fā)明內(nèi)容】

[0009]為解決上述問題，本發(fā)明實施例提供了一種集群節(jié)點縮擴的方法、設備和系統(tǒng)。
[0010]根據(jù)本發(fā)明的一個方面，提供了一種用于集群節(jié)點縮擴的方法，包括:從第一節(jié)點集群的多個第一節(jié)點接收所述多個第一節(jié)點并行生成的redis數(shù)據(jù)庫快照；從所述多個第一節(jié)點接收客戶端在所述redis數(shù)據(jù)庫快照的發(fā)送之后進行的寫操作；生成與第二節(jié)點集群的多個第二節(jié)點分別對應的附加文件，并按照所建立的key到所述第二節(jié)點集群的映射關系，將所述寫操作分別記錄在所述附加文件中；按照所述所建立的key到所述第二節(jié)點集群的映射關系，分析所述redis數(shù)據(jù)庫快照并將所述redis數(shù)據(jù)庫快照重新組合到與所述第二節(jié)點集群的所述多個第二節(jié)點分別對應的數(shù)據(jù)庫文件中；向所述多個第二節(jié)點分別發(fā)送與其對應的數(shù)據(jù)庫文件和附加文件；以及指示配置所述客戶端的配置管理系統(tǒng)將所述第二節(jié)點集群的集群節(jié)點拓撲發(fā)送到所述客戶端，以使得所述客戶端可根據(jù)所述第二節(jié)點集群的集群節(jié)點拓撲來進行讀寫操作。
[0011]根據(jù)本發(fā)明的第二方面，提供了一種用于集群節(jié)點縮擴的設備，包括:接收單元，用于從第一節(jié)點集群的多個第一節(jié)點接收所述多個第一節(jié)點并行生成的redis數(shù)據(jù)庫快照，以及從所述多個第一節(jié)點接收客戶端在所述redis數(shù)據(jù)庫快照的發(fā)送之后進行的寫操作；附加文件生成單元，用于生成與第二節(jié)點集群的多個第二節(jié)點分別對應的附加文件，并按照所建立的key到所述第二節(jié)點集群的映射關系，將所述接收單元接收到的所述寫操作分別記錄在所述附加文件中；重組合單元，用于按照所述所建立的key到所述第二節(jié)點集群的映射關系，分析所述接收單元接收到的所述redis數(shù)據(jù)庫快照并將所述redis數(shù)據(jù)庫快照重新組合到與所述第二節(jié)點集群的所述多個第二節(jié)點分別對應的數(shù)據(jù)庫文件中；發(fā)送單元，用于向所述多個第二節(jié)點分別發(fā)送與其對應的數(shù)據(jù)庫文件和附加文件，以及用于指示配置所述客戶端的配置管理系統(tǒng)將所述第二節(jié)點集群的集群節(jié)點拓撲發(fā)送到所述客戶端，以使得所述客戶端能夠根據(jù)所述第二節(jié)點集群的集群節(jié)點拓撲來進行讀寫操作。
[0012]根據(jù)本發(fā)明的第三方面，提供了一種用于集群節(jié)點縮擴的系統(tǒng)，包括:客戶端；包括多個第一節(jié)點的第一節(jié)點集群；包括多個第二節(jié)點的第二節(jié)點集群；上述用于集群節(jié)點縮擴的設備；以及用于配置所述客戶端的配置管理系統(tǒng)，所述配置管理系統(tǒng)將所述第二節(jié)點集群的集群節(jié)點拓撲發(fā)送到所述客戶端，以使得所述客戶端可根據(jù)所述第二節(jié)點集群的集群節(jié)點拓撲來進行讀寫操作。
[0013]通過使用上述的方法、設備和系統(tǒng)，解決了現(xiàn)有技術中存在的數(shù)據(jù)迀移耗時且難以在線進行的問題。
【附圖說明】
[0014]通過下面結(jié)合附圖對發(fā)明進行的詳細描述，將使本發(fā)明的上述特征和優(yōu)點更加明顯，其中:
[0015]圖1是示出根據(jù)本發(fā)明的實施例的集群節(jié)點縮擴系統(tǒng)的示意圖；
[0016]圖2是示出根據(jù)本發(fā)明的實施例的集群節(jié)點縮擴方法的流程圖；以及
[0017]圖3是示出根據(jù)本發(fā)明的實施例的集群節(jié)點縮擴設備的示意框圖。
【具體實施方式】
[0018]下面，參考附圖詳細說明本發(fā)明的優(yōu)選實施方式。在附圖中，雖然示于不同的附圖中，但相同的附圖標記用于表示相同的或相似的組件。為了清楚和簡明，包含在這里的已知的功能和結(jié)構(gòu)的詳細描述將被省略，以避免使本發(fā)明的主題不清楚。
[0019]在通常的技術方案中，redis節(jié)點數(shù)據(jù)的整體迀移依靠的是redis主從復制功能。從節(jié)點初始化時，請求主節(jié)點將那一時刻的數(shù)據(jù)快照，打包成rdb (redis db的二進制格式)發(fā)送給從節(jié)點，從節(jié)點加載rdb初始化自身內(nèi)存。同時主節(jié)點記錄了自那個快照時刻之后的所有寫操作，并按寫操作時間順序依次發(fā)生到從節(jié)點。從節(jié)點在加載的快照數(shù)據(jù)基礎上，依次執(zhí)行主節(jié)點后續(xù)發(fā)送的所有寫操作，從而達到主、從節(jié)點的數(shù)據(jù)最終一致性。
[0020]而本發(fā)明實施例所提供的方案在redis主從復制的支持下，提供一個稱為redis橋的中間件，將原有的η節(jié)點集群A，通過復制和復制過程中按key和節(jié)點的新的映射關系，將數(shù)據(jù)迀移到m個節(jié)點的集群B。迀移過程中，集群A繼續(xù)服務客戶端的讀寫請求，等到B集群已經(jīng)完整復制了數(shù)據(jù)并且追趕上了后續(xù)發(fā)生在集群A的增量寫操作，B集群的復制延時已經(jīng)非常小時，才讓B集群服務于客戶端的讀寫請求。具體地，在一些實施例中，根據(jù)業(yè)務需求允許的時間窗口，通過配置系統(tǒng)將B集群新的節(jié)點數(shù)量和編號(集群節(jié)點拓撲)發(fā)送到客戶端，同時禁止客戶端寫。在該時間窗口內(nèi)，客戶端仍然可以按照集群A節(jié)點拓撲進行只讀請求。當A和B集群數(shù)據(jù)達到完全同步的時候，配置系統(tǒng)通知客戶端按照B集群節(jié)點拓撲進行讀寫請求。至此，數(shù)據(jù)迀移和節(jié)點數(shù)量變更完成。老的集群A節(jié)點資源即可釋放。
[0021]本發(fā)明中的redis橋是實現(xiàn)了 redis復制協(xié)議的中間件。redis橋進程啟動后，作為從節(jié)點的角色連接到集群A上所有節(jié)點，請求復制。同時，它也作為主節(jié)點的角色允許B集群的所有節(jié)點連接并響應后者的復制請求。由于redis的主從復制是以節(jié)點(進程)為單位，因此本發(fā)明實施例中可以通過以連接為粒度實現(xiàn)redis的復制協(xié)議來實現(xiàn)上述多節(jié)點的從節(jié)點和主節(jié)點。
[0022]下面簡要描述用于上述本發(fā)明的設計原理的系統(tǒng)示意圖。圖1示出了根據(jù)本發(fā)明實施例的集群節(jié)點縮擴系統(tǒng)的示意圖。
[0023]如圖1所示，該系統(tǒng)包括應用程序客戶端(簡稱客戶端)、用于配置客戶端的配置管理系統(tǒng)、包括兩個節(jié)點的集群A(在本文中也稱為第一節(jié)點集群)、將要從集群A擴展到的包括三個節(jié)點的集群B (在本文中也稱為第