集群檢索平臺中的自動容災恢復方法及系統(tǒng)的制作方法
【專利摘要】本發(fā)明公開了集群檢索平臺中的自動容災恢復方法及系統(tǒng)，該方法包括：在中心節(jié)點中生成各個檢索節(jié)點的抽象，在所述檢索節(jié)點的抽象中創(chuàng)建關于該檢索節(jié)點的第一數(shù)據(jù)結構，并分別為該檢索節(jié)點承載的各個副本創(chuàng)建第二數(shù)據(jù)結構；在第一動態(tài)信息數(shù)據(jù)結構中保存當前機器狀態(tài)信息，在各個第二數(shù)據(jù)結構中保存各個副本的當前狀態(tài)信息；根據(jù)當前機器狀態(tài)信息和/或各個副本的當前狀態(tài)信息，判斷是否存在需要進行恢復的副本；如果存在，則根據(jù)當前機器狀態(tài)信息以及各個副本的當前狀態(tài)信息，為需要進行恢復的副本選擇目標檢索節(jié)點；由所述目標檢索節(jié)點根據(jù)所述索引文件提供檢索服務。通過本發(fā)明，能夠在自動容災恢復過程中，更好地保證系統(tǒng)的穩(wěn)定性。
【專利說明】集群檢索平臺中的自動容災恢復方法及系統(tǒng)【技術領域】
[0001]本申請涉及容災恢復【技術領域】，特別是涉及集群檢索平臺中的自動容災恢復方法及系統(tǒng)。
【背景技術】
[0002]對于搜索引擎而言，在索引量和搜索量大到一定程度的時候，索引更新的效率會逐漸降低，并且服務器的壓力也會逐漸升高，因此，基本上整個搜索引擎的利用率可以說是越來越低了，由此，分布式檢索技術便應運而生了。
[0003]基于服務器集群的檢索系統(tǒng)便是分布式檢索技術中的一種，這種系統(tǒng)將檢索業(yè)務部署到多個節(jié)點中。Solr是一個獨立的企業(yè)級搜索應用解決方案，在Solr的方案中，每個搜索應用會對應一個SolrCore的抽象，可以根據(jù)各個檢索業(yè)務的業(yè)務規(guī)模合理分配承載SolrCore的機器，并實現(xiàn)M*N的索引模型。在這種M*N的索引模型下，承載同一檢索業(yè)務的各臺機器在邏輯上可以組成一個M*N(M行N列)的矩陣。當在該集群中時創(chuàng)建一個檢索業(yè)務時，可以根據(jù)業(yè)務規(guī)模等為其選擇矩陣的規(guī)模(也即，確定出M與N的取值)，然后，將檢索業(yè)務的索引文件按一定的規(guī)則切分成N個分片，將各個分片分別部署到矩陣中水平向的各個不同的機器中，同樣在此切分規(guī)則之下，對數(shù)據(jù)的訪問請求也將按此規(guī)則分發(fā)到不同的機器中；同時，矩陣中位于同一列上的各個機器可以形成一個副本集，也即同一列的各個機器中保存有相同的索引文件備份，這樣可以將來自應用服務器的請求訪問(requestvisit)得以均勻的分布在同一列的各臺機器上，用以減緩單臺服務器在請求負載上的壓力。也就是說，對于一個檢索業(yè)務而言，在M*N的索引模型下，將會存在N個分片，每個分片存在M個副本，通過這種業(yè)務的劃分以及冗余機制，可以實現(xiàn)負載均衡，同時也可以實現(xiàn)容災機制，也即，由于同一分片在不同的機器中存在多個副本，因此，如果其中一臺機器宕掉，同一列中的其他機器還可以繼續(xù)提供檢索服務。
[0004]但是，當某個M*N存儲的搜索業(yè)務中的某個節(jié)點出現(xiàn)異常故障，如果M = 2，則可能導致該業(yè)務的某列的存活副本節(jié)點為1，此時，如果再出現(xiàn)該列的節(jié)點宕機，將會出現(xiàn)整個服務不可用情況。另外，當搜索業(yè)務接入方對搜索業(yè)務穩(wěn)定性的要求持續(xù)增高，基于之前固定機器節(jié)點的M*N索引模型來支持7*24小時無故障搜索服務會變的越來越不可靠。首先，機器宕機故障后，只能通過報警通知才知道節(jié)點故障，然后人工才會參與去看什么原因導致宕機；其次，如果只是應用層的故障還好，一旦是物理層的機器壞掉，如硬盤、主板壞掉，遇到這種情況，整個服務的恢復時間完全不可控。
[0005]為了避免上述現(xiàn)象的發(fā)生，需要一個監(jiān)控體系，當發(fā)現(xiàn)某個業(yè)務節(jié)點出現(xiàn)異常后，能及時準確的推選出一個或者多個空閑機器節(jié)點，以替換那些出現(xiàn)宕機的機器節(jié)點，同時快速對外提供正常的搜索服務。只有這樣，整個搜索服務出現(xiàn)問題后能較快的重新恢復到穩(wěn)定狀態(tài)，而不需要等待原來宕機的機器修復后才能恢復到穩(wěn)定狀態(tài)。
[0006]目前，有些技術方案中是可以實現(xiàn)自動的容災恢復，也即，可以自動恢復一個搜索節(jié)點替換之前出現(xiàn)問題的檢索節(jié)點。在這種自動容災恢復方案中，在發(fā)現(xiàn)一個機器宕掉之后，可以從其他的機器節(jié)點中隨機地選擇一臺機器作為恢復節(jié)點，將該出現(xiàn)問題的節(jié)點上的檢索工作轉移到該恢復節(jié)點中，以此實現(xiàn)自動容災恢復。但是，這種隨機選擇恢復節(jié)點的方式，會影響到系統(tǒng)的整體穩(wěn)定性,甚至可能會對一個檢索業(yè)務執(zhí)行容災恢復的過程中，對其他的檢索業(yè)務造成影響。因此，需要一種更可靠的自動容災恢復機制。

【發(fā)明內容】

[0007]本申請?zhí)峁┝思簷z索平臺中的自動容災恢復方法及系統(tǒng)，能夠在自動容災恢復過程中，更好地保證系統(tǒng)的穩(wěn)定性。
[0008]本申請?zhí)峁┝巳缦路桨?
[0009]一種集群檢索平臺中的自動容災恢復方法，所述集群檢索平臺包括中心節(jié)點以及用于提供檢索服務的檢索節(jié)點，所述方法包括:
[0010]在所述中心節(jié)點中生成各個檢索節(jié)點的抽象，在所述檢索節(jié)點的抽象中創(chuàng)建關于該檢索節(jié)點的第一數(shù)據(jù)結構，并分別為該檢索節(jié)點承載的各個副本創(chuàng)建第二數(shù)據(jù)結構；
[0011]在所述第一動態(tài)信息數(shù)據(jù)結構中保存所述檢索節(jié)點上傳的當前機器狀態(tài)信息，在各個第二數(shù)據(jù)結構中保存所述檢索節(jié)點上傳的各個副本的當前狀態(tài)信息；
[0012]根據(jù)所述當前機器狀態(tài)信息和/或各個副本的當前狀態(tài)信息，判斷是否存在需要進行恢復的副本；
[0013]如果存在，則根據(jù)所述當前機器狀態(tài)信息以及各個副本的當前狀態(tài)信息，為所述需要進行恢復的副本選擇目標檢索節(jié)點；
[0014]將所述需要進行恢復的副本對應的索引文件拷貝到所述目標檢索節(jié)點中，由所述目標檢索節(jié)點根據(jù)所述索引文件提供檢索服務。
[0015]一種集群檢索平臺中的自動容災恢復系統(tǒng)，所述集群檢索平臺包括中心節(jié)點以及用于提供檢索服務的檢索節(jié)點，所述系統(tǒng)包括:
[0016]數(shù)據(jù)結構創(chuàng)建單元，用于在所述中心節(jié)點中生成各個檢索節(jié)點的抽象，在所述檢索節(jié)點的抽象中創(chuàng)建關于該檢索節(jié)點的第一數(shù)據(jù)結構，并分別為該檢索節(jié)點承載的各個副本創(chuàng)建第二數(shù)據(jù)結構；
[0017]信息保存單元，用于在所述第一動態(tài)信息數(shù)據(jù)結構中保存所述檢索節(jié)點上傳的當前機器狀態(tài)信息，在各個第二數(shù)據(jù)結構中保存所述檢索節(jié)點上傳的各個副本的當前狀態(tài)信息；
[0018]判斷單元，用于根據(jù)所述當前機器狀態(tài)信息和/或各個副本的當前狀態(tài)信息，判斷是否存在需要進行恢復的副本；
[0019]節(jié)點選擇單元，用于如果存在需要進行恢復的副本，則根據(jù)所述當前機器狀態(tài)信息以及各個副本的當前狀態(tài)信息，為所述需要進行恢復的副本選擇目標檢索節(jié)點；
[0020]恢復單元，用于將所述需要進行恢復的副本對應的索引文件拷貝到所述目標檢索節(jié)點中，由所述目標檢索節(jié)點根據(jù)所述索引文件提供檢索服務。
[0021]根據(jù)本申請?zhí)峁┑木唧w實施例，本申請公開了以下技術效果:
[0022]通過本申請,可以抽象出一個中心節(jié)點CenterNode來掌控搜索平臺中所有檢索節(jié)點上的機器狀態(tài)，以及各個檢索節(jié)點上承載的所有業(yè)務的副本狀態(tài)，這樣，就可以根據(jù)這些狀態(tài)信息來確定是否存在需要進行恢復的副本，如果存在，還可以根據(jù)機器狀態(tài)信息以及副本的狀態(tài)信息，來綜合選擇出最合適的目標檢索節(jié)點，然后就可以在該節(jié)點上對副本進行恢復?？梢?，在本申請實施例中，在選擇用于進行副本恢復的目標檢索節(jié)點時，可以以各個檢索節(jié)點的機器狀態(tài)以及各個檢索節(jié)點中各個業(yè)務副本的狀態(tài)為依據(jù)，而不是進行隨機選擇，因此，可以在自動容災恢復過程中，更好地保證系統(tǒng)的穩(wěn)定性。
[0023]當然，實施本申請的任一產(chǎn)品并不一定需要同時達到以上所述的所有優(yōu)點。
【專利附圖】

【附圖說明】
[0024]為了更清楚地說明本申請實施例或現(xiàn)有技術中的技術方案，下面將對實施例中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本申請的一些實施例，對于本領域普通技術人員來講，在不付出創(chuàng)造性勞動的前提下，還可以根據(jù)這些附圖獲得其他的附圖。
[0025]圖1是本申請實施例提供的方法的流程圖；
[0026]圖2是本申請實施例提供的搜索平臺中業(yè)務發(fā)布過程的流程圖；
[0027]圖3是本申請實施例提供的狀態(tài)信息獲取方式的示意圖；
[0028]圖4是本申請實施例提供的系統(tǒng)的示意圖。
【具體實施方式】
[0029]下面將結合本申請實施例中的附圖,對本申請實施例中的技術方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是本申請一部分實施例，而不是全部的實施例?；诒旧暾堉械膶嵤├?，本領域普通技術人員所獲得的所有其他實施例，都屬于本申請保護的范圍。
[0030]為了能夠提供一個更可靠的自動容災恢復機制，本申請實施例首先抽象出一個中心節(jié)點CenterNode來掌控搜索平臺中所有業(yè)務的搜索引擎狀態(tài)，并且通過狀態(tài)信息分析來決定集群機器的下一步的動作是什么，比如，容災恢復、組內擴容等。同時，集群中還存在檢索節(jié)點CoreNode,該節(jié)點用于提供檢索服務的節(jié)點，負責從CenterNode的任務池領取任務指令進行具體業(yè)務的引擎SolrCore (也即檢索業(yè)務某分片的一個副本)的創(chuàng)建、變更、刪除等動作，同時在引擎SolrCore對象正常創(chuàng)建后提供檢索服務。
[0031]需要說明的是，在本申請實施例中，CoreNode中承載的副本也稱為SolrCore副本，從功能上講，其實是具體的檢索業(yè)務的業(yè)務引擎，能夠對外提供檢索業(yè)務。
[0032]參見圖1，本申請實施例提供的集群檢索平臺中的自動容災恢復方法可以包括以下步驟:
[0033]SlOl:在所述中心節(jié)點中生成各個檢索節(jié)點的抽象，在所述檢索節(jié)點的抽象中創(chuàng)建關于該檢索節(jié)點的第一數(shù)據(jù)結構，并分別為該檢索節(jié)點承載的各個副本創(chuàng)建第二數(shù)據(jù)結構；
[0034]S102:在所述第一動態(tài)信息數(shù)據(jù)結構中保存所述檢索節(jié)點上傳的當前機器狀態(tài)信息，在各個第二數(shù)據(jù)結構中保存所述檢索節(jié)點上傳的各個副本的當前狀態(tài)信息；
[0035]在具體實現(xiàn)時，中心節(jié)點能夠與檢索節(jié)點之間進行通信，檢索節(jié)點可實時上傳狀態(tài)信息到中心節(jié)點，中心節(jié)點進行保存，進而利用保存的狀態(tài)信息執(zhí)行后續(xù)的恢復需求判斷以及目標檢索節(jié)點的選擇等操作。其中，中心節(jié)點為了對這些狀態(tài)信息進行保存，可在中心節(jié)點中為各個檢索節(jié)點創(chuàng)建對應的檢索節(jié)點抽象:CorenodeDescrptor,在該CorenodeDescrptor中可以為各個檢索節(jié)點創(chuàng)建用于保存機器狀態(tài)信息的第一數(shù)據(jù)結構，以及分別用于保存檢索節(jié)點中承載的各個SolrCore的狀態(tài)信息的第二數(shù)據(jù)結構:動態(tài)DynCore0
[0036]其中，關于中心節(jié)點CenterNode與檢索節(jié)點CoreNode之間具體如何進行信息的交互，下面進行詳細地介紹。
[0037]在CoreNode啟動后,將立即和CenterNode進行通信，同時自身將生成身份令牌并向CenterNode注冊，該身份令牌可以包括一個隨機數(shù)+IP地址+Port+當前系統(tǒng)時間等，CenterNode校驗版本信息和令牌合法性后,查看該CoreNode是否是已經(jīng)注冊過的機器,有兩種處理情況:
[0038]如果是未注冊機器，CenterNode將找不到對應CoreNode的CoreNodeDescript1r(CoreNode 節(jié)點抽象)，這個時候 CenterNode 初始化一個CoreNodeDescr ipt1r，并將它的存活狀態(tài)置為Online，然后將它加入到內存中存活機器列表池中(一個鏈表的數(shù)據(jù)結構)；
[0039]如果是已經(jīng)注冊過的機器，CenterNode將找到對應該CoreNode節(jié)點身份令牌的CoreNodeDescript1r,然后更新該節(jié)點抽象的基本信息,如IP、Port等信息。最后返回給CoreNode注冊成功信息。
[0040]同時CoreNode如果是第一次注冊，注冊成功后將持久化身份令牌到本地，之后機器節(jié)點的重啟導致的再次注冊，都將用第一次持久化的身份令牌向CenterNode注冊。
[0041]所有加入搜索集群中的CoreNode在承載SolrCore引擎的時候都是空閑節(jié)點，并不會提供任何的搜索服務出去(因為CoreNode中還沒有保存索引文件等相關數(shù)據(jù))。這個時候需要在后臺進行具體業(yè)務的SolrCore引擎發(fā)布,才能讓新的SolrCore引擎創(chuàng)建。整個執(zhí)行流程為如圖2所示。
[0042]S201:CoreNode 選擇:
[0043]CoreNode 成功注冊 CenterNode 后,CenterNode 將會有一個對應該 CoreNode 的抽象，如果該CoreNode沒有出現(xiàn)巖機,該抽象將會一直在CenterNode存在,在ManagerNode節(jié)點(該節(jié)點為整個引擎平臺的后臺管理節(jié)點，負責所有接入業(yè)務的發(fā)布和擴容、配置變更等指令觸發(fā)，并提供整個引擎平臺所有業(yè)務搜索引擎的狀態(tài)信息可視化查詢)通過頁面選擇好對應某個業(yè)務的CoreNode節(jié)點。選擇規(guī)范必須滿足M*N模型，即一個業(yè)務可以存在多個Shard分片、每個Shard分片存在多個副本。M*N的結構的索引存儲結構可以有效解決負載均衡和巖機容災問題。在ManagerNode節(jié)點需要做的是定義好數(shù)據(jù)模型的M、N的數(shù)目和每個矩陣對應的CoreNode機器IP。
[0044]S202:創(chuàng)建指令觸發(fā):
[0045]選擇好所有的CoreNode機器后，點擊創(chuàng)建指令，MangerNode將該任務指令通過進程RPC協(xié)議通知到CenterNode。CenterNode接到指令后將對該指令的業(yè)務名稱進行校驗，如果發(fā)現(xiàn)這個業(yè)務已經(jīng)創(chuàng)建過，將返回錯誤給MangerNode。如果沒有該業(yè)務對應的SolrCore引擎生成,貝U開始創(chuàng)建。
[0046]S203:NSEditLog 記錄操作:
[0047]創(chuàng)建操作的執(zhí)行將會有一個預寫事務日志(WAL) NSEditLog來保證節(jié)點崩潰時對SolrCore的創(chuàng)建操作的持久化。節(jié)點崩潰后重啟將重做NSEditLo的記錄,讓節(jié)點內存中的數(shù)據(jù)結構恢復到崩潰前的狀態(tài)。CenterNode重啟過程中將會根據(jù)NSEditLog文件的記錄按照順序重做操作內容，從而讓內存中數(shù)據(jù)結構恢復到宕機前某個時間點。
[0048]S204:NameSpaceFile 生成:
[0049]NSEditLog記錄生成后,對應的NameSpaceFile在內存的結構也就生成,從內存結構上看為:Generat1nStamp創(chuàng)建時間戮記錄、NameSpaceFile路徑記錄、NameSpaceFile路徑修改、訪問時間記錄、NameSpaceFile文件內容記錄，主要內容包括文件業(yè)務名、Shard數(shù)目、副本數(shù)目、修改時間、訪問時間和該業(yè)務對應的SolrCore抽象Core的列表記錄。NameSpaceFile是一個搜索業(yè)務在CenterNode中的一個管理抽象和業(yè)務抽象，而CenterNode對于每個業(yè)務的管理和操作都是基于NameSpaceFile進行，例如:擴容，容災
坐寸ο
[0050]S205:提交任務到任務池:
[0051]當一個業(yè)務歸屬的NameSpaceFile生成完畢后，接下來就需要將這個創(chuàng)建操作以任務的方式放入已經(jīng)選擇好CoreNode對應的CorenodeDescriptor抽象的任務池中。
[0052]S206:CoreNode 領取任務:
[0053]當選擇的CoreNode在一個心跳周期和CenterNode通過RPC通信后，將會到該CoreNode對應的CorenodeDescriptor任務池中領取到這個CoreNode需要執(zhí)行的任務，同時將任務和需要創(chuàng)建的SolrCore對應的唯一身份CoreId連同任務類型一起封裝成CoreNodeCommand 返回給請求的 CoreNode。
[0054]S207:SolrCore 創(chuàng)建:
[0055]CoreNode節(jié)點心跳通信返回后，獲取到指定的任務指令CoreNodeCommand，根據(jù)CoreNodeCommand任務類型選擇相應任務執(zhí)行。如果是SolrCore創(chuàng)建，CoreNode將會執(zhí)行如下操作:
[0056]I)到ManagerNode去拉最新版本的SolrCore所需要的配置文件(schema, xml、solrConfig.xml 等)；
[0057]2) CoreNode 加載 schema, xml 和 solrConf ig.xml 配置文件生成 SolrCore 對象；
[0058]3)將CoreNodeCommand中對應創(chuàng)建具體SolrCore唯一身份標不coreld和執(zhí)行狀態(tài)信息持久化到本地；
[0059]4)將創(chuàng)建SolrCore是否成功的標示通知到CenterNode。
[0060]成功創(chuàng)建完SolrCore之后，該引擎節(jié)點并沒有任何索引數(shù)據(jù)，這個時候CenterNode接受到該應用所有M*N個SolrCore的成功創(chuàng)建通知后，將進行全量任務指令放入這些Solrcore對應的CorenodeDescriptor任務池中。接下來對應的CoreNode通過心跳通信領取全量任務進行全量。
[0061]每個SolrCore全量完畢后，將執(zhí)行狀態(tài)信息通知CenterNode，CenterNode收集到這個業(yè)務歸屬的所有SolrCore的全量執(zhí)行成功通知后，將進行搜索服務發(fā)布的任務指令放入到這些SolrCore對應的CorenodeDescriptor任務池中。接下來，對應的CoreNode通過心跳通信領取搜索服務發(fā)布任務。
[0062]每個SolrCore的搜索服務發(fā)布后，將執(zhí)行狀態(tài)信息通知CenterNode，CenterNode收集到這個業(yè)務歸屬的所有SolrCore搜索服務發(fā)布成功通知后，將調用NSEditLog的0P—CLOSE操作，該操作將記錄NameSpaceFile已經(jīng)成功創(chuàng)建。
[0063]S208:動態(tài)信息變更:
[0064]參見圖3,本申請實施例中的動態(tài)信息收集示意圖,其中，DynCore是一個對具體CoreNode承載的SolrCore副本的抽象,一旦某個業(yè)務的一個分片下的副本在CoreNode成功創(chuàng)建后，則被中心節(jié)點的CorenodeDescriptor所創(chuàng)建并管理,也就是說哪個CoreNode承載了 SolrCore的副本，那么就會在CorenodeDescriptor存在一個對應的DynCore。
[0065]同時，圖2中可以看出，中心節(jié)點還可以存在NameSpaceFile,它是在創(chuàng)建一個搜索業(yè)務的時候就會在CenterNode生成的一個內存數(shù)據(jù)結構，主要內容包括該業(yè)務有幾個分片、有幾個副本、涉及配置文件名稱等。比如，某個業(yè)務存在3個分片，那么就會在NameSpaceFile存在3個Core的抽象。這些信息基本是一旦發(fā)布后都不大會改變，除非出現(xiàn)擴容情況。
[0066]例如，圖3說明一個分片為3，副本數(shù)為2的搜索業(yè)務分布在CoreNodeA、CoreNodeB、CoreNodeC中，每次CoreNode通過心跳通信，首先找到對應CoreNode的CorenodeDescriptor,并根據(jù)每個SolrCore副本對應的唯一身份coreld找到DynCore,然后更新這個DynCore的狀態(tài)信息，這樣每個機器中承載的各個SolrCore副本的狀態(tài)信息都能在CenterNode有個內存映射。例如圖2中搜索服務分片I和分片O的SolrCore副本抽象 DynCore 在 CorenodeDescriptorA 中，并同時對應著 NameSpaceFile 的 Core-Ο 對象，其他依次類推。同時，在中心節(jié)點的CorenodeDescriptor中還可存儲有用于保存各個機器狀態(tài)信息(包括可用磁盤空間大小、可用內存大小、當前負載的大小、CPU核心數(shù)量等)的數(shù)據(jù)結構(圖中未示出)。
[0067]其中，DynCore主要管理SolrCore副本實時更新一些狀態(tài)信息,包括:
[0068]SolrCore對應的Solr和Lucene引擎版本信息；
[0069]SolrCore對應業(yè)務名稱；
[0070]SolrCore實例的系統(tǒng)路徑；
[0071]SolrCore實例對應索引的存儲路徑；
[0072]SolrCore實例的索引大小；
[0073]SolrCore對應索引數(shù)據(jù)量大??；
[0074]SolrCore的執(zhí)行狀態(tài)信息(創(chuàng)建中、創(chuàng)建成功、全量中、全量成功、發(fā)布搜索服務等)；
[0075]SolrCore 創(chuàng)建時間；
[0076]SolrCore搜索請求數(shù)；
[0077]SolrCore平均每秒響應多少次請求；
[0078]SolrCore每次請求平均響應時間；
[0079]SolrCore請求超時數(shù)；
[0080]SolrCore緩存狀態(tài)信息(緩存大小、累計命中率、累計淘汰個數(shù)等)。
[0081]也就是說，CoreNode節(jié)點和CenterNode節(jié)點間的通信可以分為:
[0082]心跳通信(SendHeartbeat)；
[0083]健康狀態(tài)匯報(CoreReport)。
[0084]其中，心跳通信主要是CoreNode將機器狀態(tài)信息(包括CPU核心數(shù)量、可用內存大小、可以磁盤大小、搜索監(jiān)控指標信息等)每隔一定時間(例如，三秒)匯報給CenterNode, CenterNode在前述第一數(shù)據(jù)結構中保存該機器狀態(tài)信息。
[0085]而健康狀態(tài)匯報是將該CoreNode上承載的所有SolrCore副本的健康狀態(tài)信息上報給CenterNode,如SolrCore執(zhí)行狀態(tài)、是否正常工作等信息，以一定的間隔(例如3分鐘)匯報給CenterNode節(jié)點，CenterNode在前述各個第二數(shù)據(jù)結構中保存各個SolrCore副本的狀態(tài)信息。
[0086]S103:根據(jù)所述當前機器狀態(tài)信息和/或各個副本的當前狀態(tài)信息，判斷是否存在需要進行恢復的副本；
[0087]由于中心節(jié)點CenterNode記錄了各個CoreNode的機器狀態(tài)信息，以及各個CoreNode中承載的各個SolrCore副本的狀態(tài)信息，因此，可以根據(jù)這些信息可以及時發(fā)現(xiàn)需要進行恢復的副本。并且，由于中心節(jié)點記錄的信息中不僅僅包括機器狀態(tài)信息，還包括CoreNode中承載的各個SolrCore副本的狀態(tài)信息，因此，中心節(jié)點不僅能發(fā)現(xiàn)機器宕機情況下需要恢復的副本，還可以發(fā)現(xiàn)在機器沒有宕機但是副本運行不正常時需要恢復的副本。
[0088]也就是說，在確定需要恢復的副本時，本申請實施例中一方面可以判斷是否有檢索節(jié)點CoreNode發(fā)生了巖機，如果是，則可以將該CoreNode中承載的各個SolrCore副本都確定為需要進行恢復的SolrCore副本。
[0089]其中，具體在判斷是否有CoreNode發(fā)生了巖機時，CenterNode可在后臺有一個HeartbeatMonitor線程去判斷CoreNode是否巖機，每個CoreNode通過心跳通信后都將更新CenterNode中對應的CorenodeDescriptor中的las tupdatTime為當前更新時間，在HeartbeatMonitor每隔一段時間進行輪詢檢查的時候，如果發(fā)現(xiàn)某個CorenodeDescriptor對應的IastupdateTime小于當前時間減去一個預置的安全時間間隔(IastupdateTime < currentTime-heartbeatExp ire Interval)，那么就會認為該 Corenode已經(jīng)巖機，一旦發(fā)現(xiàn)該情況，CenterNode將會認為這個CoreNode承載的所有SolrCore副本都為不正常狀態(tài)，并將該CoreNode承載的所有SolrCore副本都加入到待恢復列表中(neededReplicat1ns)。
[0090]需要說明的是，在實際應用中，在通過上述方式來確定需要恢復的SolrCore副本時,加入到待恢復列表中的SolrCore副本可能會有誤判情況。例如，如果某CoreNodeA當前因為網(wǎng)絡、或者人工重啟，導致在一個安全時間間隔沒有和CenterNode進行心跳檢查，這個時候CenterNode會誤判該CoreNodeA已經(jīng)巖機,并將其承載的SolrCore都加入到待恢復列表中。此時，如果直接對這些SolrCore副本都進行恢復，將會出現(xiàn)多余的副本,這將破壞原有的M*N模型，使得系統(tǒng)不夠穩(wěn)定。為了避免這種情況的發(fā)生，在本申請實施例中每次恢復操作之前，還可以檢查待恢復的SolrCore副本當前在集群中總的副本存活數(shù)(因為一個SolrCore副本在矩陣的同一列中的M個機器中均存在SolrCore副本，因此，可以分別檢查這M個機器中承載的這些SolrCore副本是否為存活狀態(tài)，由此可以統(tǒng)計出存活副本的數(shù)目)，如果在此之前，該CoreNodeA又有匯報上來并且其中承載的SolrCore副本已經(jīng)正常，則統(tǒng)計出的存活副本的數(shù)量可能是正常的(例如等于為對應的檢索業(yè)務分配的副本數(shù)量)，因此，就可以直接將這些待恢復的SolrCore副本清除出列表，不再對其進行恢復。當然，如果是在執(zhí)行了恢復任務之后，CoreNodeA才匯報上來并且其中承載的SolrCore副本已經(jīng)正常，那么就會出現(xiàn)多余副本情況，這個時候CenterNode后臺會仍然會監(jiān)控這個副本存活數(shù)，如果存活副本數(shù)目大于實際為對應的檢索業(yè)務分配的副本數(shù)，可觸發(fā)一個刪除多余副本數(shù)操作，將該業(yè)務下多余的副本進行刪除。
[0091]另外，本申請實施例還可以根據(jù)CoreNode的健康狀態(tài)上報的SolrCore副本的狀態(tài)信息，來判斷是否存在某個SolrCore副本已經(jīng)不正常，如果存在，則CenterNode將該SolrCore副本加入到需要進行副本恢復的列表(neededReplicat1ns)中。
[0092]也就是說，對于一個CoreNode節(jié)點而言，可能并未發(fā)生宕機，但其中承載的SolrCore副本卻可能已經(jīng)不正常了，原因可能是索引文件被損壞等等。在本申請實施例中，由于中心節(jié)點能夠監(jiān)控到各個CoreNode承載的各個SolrCore副本的狀態(tài)信息，因此,如果發(fā)生該現(xiàn)象，則中心節(jié)點能夠及時發(fā)現(xiàn)，然后將該不正常的SolrCore副本作為需要恢復的SolrCore 副本。
[0093]具體地，在判斷是否存在不正常的SolrCore副本時，可以根據(jù)CoreNode節(jié)點上報的副本狀態(tài)信息進行分析，如果其中某些信息項存在明顯的錯誤，或者上報的副本狀態(tài)信息中存在CoreNode節(jié)點添加的錯誤標識，則可以確定對應的SoIrCore副本已經(jīng)不正常?；蛘?，還有些情況是，CoreNode節(jié)點應該為某SolrCore副本上報狀態(tài)信息，但是，CenterNode在一定的時間間隔內卻沒有收到關于該SolrCore副本的狀態(tài)信息,此時,CenterNode可以認為該SolrCore副本歸屬的檢索業(yè)務應該是被刪除了，因此，可以不必將其加入副本恢復列表中。
[0094]S104:如果存在，則根據(jù)所述當前機器狀態(tài)信息以及各個副本的當前狀態(tài)信息，為所述需要進行恢復的副本選擇目標檢索節(jié)點；
[0095]對于需要進行恢復的副本而言，如果要進行恢復，首先可確定在哪個CoreNode節(jié)點中進行恢復，在本申請實施例中，并不是隨機地進行選擇，這是因為，其他的CoreNode節(jié)點可能同時承載有其他檢索業(yè)務的副本，并且可能已經(jīng)是負載特別重的機器，如CPU的負載特別高、內存已經(jīng)沒有多少空閑、磁盤空間已經(jīng)不夠等；另外一種情況，有些CoreNode節(jié)點已經(jīng)承載了核心業(yè)務的SolrCore搜索引擎，是不能容忍其他業(yè)務SolrCore引擎被承載。另外，如果某個CoreNode節(jié)點正在執(zhí)行恢復操作，則如果向該CoreNode節(jié)點分配恢復任務，也可能會導致不穩(wěn)定?？傊?，如果盲目地選擇，可能會對其他檢索業(yè)務產(chǎn)生影響，或者使得整個系統(tǒng)的負載不夠均衡，影響系統(tǒng)效率，等等。
[0096]因此，在本申請實施例中，對機器的自動推選應該根據(jù)如下幾種策略:
[0097]排除標示為不能承載其他業(yè)務的CoreNode ；
[0098]排除磁盤空間不足的CoreNode ；
[0099]排除已經(jīng)被分配恢復任務并正在進行恢復的CoreNode。
[0100]對于剩余的CoreNode，根據(jù)CoreNode的多種維度(機器狀態(tài)維度以及副本狀態(tài)維度)加維度權重影響的打分排序，分數(shù)越高代表CoreNode越空閑。
[0101 ] 在CenterNode中推選出最空閑機器其實就是推選出集群中所有CoreNode在CenterNode 中對應的 CorenodeDescriptor 的過程。CorenodeDescriptor 對象中會有一個Exclusive屬性，如果為TRUE,則代表該CorenodeDescriptor只為一個業(yè)務的SolrCore獨占。一旦設置為TRUE后，該節(jié)點就不會在自動推選最空閑機器結果集中出現(xiàn)，即使它的Load很低、內存、磁盤都很充裕。而Exclusive為FALSE的CorenodeDescriptor都可以根據(jù)打分機制被推選出來，作為進行容災恢復的CoreNode節(jié)點。
[0102]一個業(yè)務引擎索引所需要的磁盤空間大概是當前索引的兩倍左右，這是因為在全量任務結束后從HDFS中拷貝索引到本地，會出現(xiàn)新老索弓I并存情況，那么在全量切換時刻磁盤占用將會達到原來索引容量的兩倍左右，所以在選擇CoreNode的時候通常需要滿足:當前磁盤空閑空間減去待恢復業(yè)務的索引磁盤容量的2倍(diskRemain-2*diskUsed > O)大于O,如果不滿足要求則將該CoreNode進行過濾,剩余滿足磁盤空閑條件的CoreNode進入下一個過濾環(huán)節(jié)。
[0103]CoreNode 在 CenterNode 中的抽象 CorenodeDescriptor — 旦被選中作為待恢復的節(jié)點后，在整個容災恢復過程未完成前將不會再被選中為待恢復節(jié)點。從neededReplicat1ns待恢復列表中優(yōu)先級最高的待恢復SolrCore選擇合適的CorenodeDescriptor后,會將恢復任務放入pendingReplicat1ns (正在恢復列表)，凡是在正在恢復列表中的CorenodeDescriptor將不會再選中為待恢復機器。但是整個恢復過程會存在失敗情況，所以，后臺可以有線程去校驗在一個安全預置時間內正在恢復的任務是否成功結束，如果沒有，則認為該恢復任務失敗，將該任務從pendingReplicat1ns清除，并將該任務重新放入neededReplicat1ns中，而此時CorenodeDescriptor又可以作為新的SolrCore待恢復的節(jié)點。
[0104]滿足上述3個篩選條件后的機器節(jié)點將可基于如下2個大維度進行權重影響排序:
[0105]機器維度:
[0106]diskRemain:磁盤剩余空間
[0107]totalPhysicalMemorySize:內存大小
[0108]availabIeProcessors:CPU 核數(shù)
[0109]syStemLoadAverage:機器當前 Load 大小
[0110]業(yè)務SolrCore引擎維度:
[0111]coreNum:承載 SolrCore 的個數(shù)
[0112]avgTimePerRequest:每次請求的平均響應時間
[0113]上述兩個維度可以按照權重影響的兩種優(yōu)先級進行篩選排序:
[0114]優(yōu)先級1:
[0115]如果CoreNode沒有承載任何SolrCore副本，即發(fā)現(xiàn)CorenodeDescriptor中并沒有DynCore被分配，則將會認為是最空閑的機器，所以從排序計算來看coreNum為O的機器優(yōu)先級為I (即將設置較大的權重值)，同時CoreNode的得分激勵將會越高；如果多個CoreNode都沒有承載SolrCore副本，則將磁盤空閑大的排序優(yōu)先，磁盤一樣的話則將可用內存較大的優(yōu)先排序。所以優(yōu)先級I下多個維度的權重值是:coreNum = O >磁盤空間>內存。
[0116]優(yōu)先級2:
[0117]如果CoreNode有承載SolrCore副本,則機器負載load為最大權重考慮，load越小分數(shù)越高，Load 一致情況下，再以coreNum維度打分，coreNum越小則分數(shù)越高(coreNum越小代表部署的業(yè)務引擎副本越小，意味著影響面越小)。如果coreNum相同將會根據(jù)SolrCore平均每次請求響應時間(avgTimePerRequest,請求響應越小代表該節(jié)點的查詢性能越好)來比較，avgTimePerRequest越低打分越高。所以優(yōu)先級2下多維度的權重值為 load > coreNum > avgTimPerRequests。
[0118]最終，在自動容災過程中被推選出來的用于進行恢復的CoreNode節(jié)點，滿足以下條件:
[0119]不被某一業(yè)務獨占的；
[0120]能承載2倍待恢復業(yè)務索引磁盤空間的數(shù)據(jù)；
[0121]優(yōu)先推選出集群中未部署業(yè)務引擎的并且是磁盤和內存較充裕的機器；
[0122]如果發(fā)現(xiàn)沒有未部署業(yè)務引擎的機器節(jié)點，則選擇出Load、承載引擎、平均響應時間較低的機器。
[0123]S105:將所述需要進行恢復的副本對應的索引文件拷貝到所述目標檢索節(jié)點中，由所述目標檢索節(jié)點根據(jù)所述索引文件提供檢索服務。
[0124]副本恢復過程具體為，將待恢復列表中的SolrCore抽象重新創(chuàng)建，CenterNode后臺會有Replicat1nMonitor每隔一個時間間隔將待恢復列表中需要進行恢復的solrCore副本進行重新構建操作。
[0125]被選擇的用于進行副本恢復的目標CoreNode節(jié)點從CenterNode獲取任務后，開始進行SolrCore副本構建,大體流程和前文所述的SolrCore創(chuàng)建的流程一致,唯一不一樣的是構建成功后將不會重新全量，也不是從其他正在運行的節(jié)點中去拷貝索引文件，而是從分布式平臺(如Hadoop等，負責整個引擎平臺所有業(yè)務引擎所需要的源數(shù)據(jù)和索引數(shù)據(jù)的存儲)的HDFS文件系統(tǒng)上拉取最新的全量索引到本地，同時增補已經(jīng)在HDFS上并且是全量時間點Timepoint后到目前為止的增量數(shù)據(jù)為索引，最后發(fā)布搜索服務，這樣業(yè)務方的搜索請求就能進入到最新構建的CoreNode中來，整個過程對于業(yè)務方完全透明。
[0126]總之,在本申請實施例中，可以抽象出一個中心節(jié)點CenterNode來實時掌控搜索平臺中所有檢索節(jié)點上的機器狀態(tài)，以及各個檢索節(jié)點上承載的所有業(yè)務的副本狀態(tài)，這樣，就可以根據(jù)這些狀態(tài)信息來確定是否存在需要進行恢復的副本，如果存在，還可以根據(jù)機器狀態(tài)信息以及副本的狀態(tài)信息，來綜合選擇出最合適的目標檢索節(jié)點，然后就可以在該節(jié)點上對副本進行恢復?？梢?，在本申請實施例中，在選擇用于進行副本恢復的目標檢索節(jié)點時，可以以各個檢索節(jié)點的機器狀態(tài)以及各個檢索節(jié)點中各個業(yè)務副本的狀態(tài)為依據(jù)，而不是進行隨機選擇，因此，可以在自動容災恢復過程中，更好地保證系統(tǒng)的穩(wěn)定性。
[0127]與本申請實施例提供的集群檢索平臺中的自動容災恢復方法相對應，本申請實施例還提供了一種集群檢索平臺中的自動容災恢復系統(tǒng)，參見圖4，所述集群檢索平臺包括中心節(jié)點以及用于提供檢索服務的檢索節(jié)點，所述系統(tǒng)包括:
[0128]數(shù)據(jù)結構創(chuàng)建單元401，用于在所述中心節(jié)點中生成各個檢索節(jié)點的抽象，在所述檢索節(jié)點的抽象中創(chuàng)建關于該檢索節(jié)點的第一數(shù)據(jù)結構，并分別為該檢索節(jié)點承載的各個副本創(chuàng)建第二數(shù)據(jù)結構；
[0129]信息保存單元402，用于在所述第一動態(tài)信息數(shù)據(jù)結構中保存所述檢索節(jié)點實時上傳的當前機器狀態(tài)信息，在各個第二數(shù)據(jù)結構中保存所述檢索節(jié)點實時上傳的各個副本的當前狀態(tài)信息；
[0130]判斷單元403，用于根據(jù)所述當前機器狀態(tài)信息和/或各個副本的當前狀態(tài)信息，判斷是否存在需要進行恢復的副本；[0131]節(jié)點選擇單元404，用于如果存在需要進行恢復的副本，則根據(jù)所述當前機器狀態(tài)信息以及各個副本的當前狀態(tài)信息，為所述需要進行恢復的副本選擇目標檢索節(jié)點；
[0132]恢復單元405，用于將所述需要進行恢復的副本對應的索引文件拷貝到所述目標檢索節(jié)點中，由所述目標檢索節(jié)點根據(jù)所述索引文件提供檢索服務。
[0133]具體在判斷是否存在需要恢復的副本時，可以有多種方式，在其中一種方式下，所述當前機器狀態(tài)信息中保存有所述檢索節(jié)點上傳所述機器狀態(tài)信息時的最近更新時間信息，所述判斷單元403可以包括:
[0134]第一確定子單元，用于判斷所述最近更新時間是否小于當前時間與預置的安全時間間隔的差值，如果是，則確定所述檢索節(jié)點發(fā)生宕機，并將該檢索節(jié)點中承載的各個副本均確定為需要進行恢復的副本。
[0135]為了避免發(fā)生誤判，該系統(tǒng)還可以包括:
[0136]取消單元，用于在將所述需要進行恢復的副本對應的索引文件拷貝到所述目標檢索節(jié)點中之前，根據(jù)各個檢索節(jié)點上傳的各個副本的當前狀態(tài)信息，查詢各個副本的當前存活數(shù)量，如果存活數(shù)量等于為對應檢索業(yè)務分配的副本數(shù)量，則取消對該檢索節(jié)點中承載的各個副本的恢復操作。
[0137]在另一種方式下，所述判斷單元403可以包括:
[0138]第二確定子單元，用于根據(jù)所述各個副本的當前狀態(tài)信息，判斷某正常運行的檢索節(jié)點中是否存在不正常的副本，如果是，則將該不正常的副本確定為需要進行恢復的副本。具體的，如果某副本的當前狀態(tài)信息中顯示該副本在運行中存在錯誤(例如檢索文件被損壞等等)，則將該副本確定為不正常的副本。
[0139]具體在進行節(jié)點選擇時，需要綜合機器狀態(tài)以及機器中副本的狀態(tài)來綜合考慮，所述節(jié)點選擇單元404可以包括:
[0140]過濾子單元，用于將標識為不能承載其他檢索業(yè)務的檢索節(jié)點、機器負載超出預置閾值的檢索節(jié)點、以及正在執(zhí)行副本恢復的檢索節(jié)點排除；
[0141]排序子單元，用于將剩余的檢索節(jié)點，從機器狀態(tài)維度以及副本狀態(tài)維度進行綜合排序，并根據(jù)排序結果確定目標檢索節(jié)點；其中，所述機器狀態(tài)維度包括磁盤剩余空間、可用內存、中央處理單元CPU核心的數(shù)量以及機器負載中的一種或多種，所述副本狀態(tài)維度包括當前檢索節(jié)點中承載的副本數(shù)量和/或每次請求時的平均響應時間。
[0142]其中，所述排序子單元包括:
[0143]第一權重確定子單元，用于對于承載的副本數(shù)量為O的檢索節(jié)點，磁盤剩余空間越大權重越聞，磁盤剩余空間相等時，可用內存越大權重越聞;
[0144]第二權重確定子單元，用于對于承載的副本數(shù)量不為O的檢索節(jié)點，則機器負載越小權重越聞，機器負載相等時，承載的副本數(shù)量越少權重越聞，承載的副本數(shù)量也相等時,每次請求時的平均響應時間越短權重越高。
[0145]另外，該系統(tǒng)還可以包括:
[0146]優(yōu)先級確定單元，用于在將所述需要進行恢復的副本對應的索引文件拷貝到所述目標檢索節(jié)點中之前，根據(jù)各個檢索節(jié)點上傳的各個副本的當前狀態(tài)信息，查詢各個需要進行恢復的副本的當前存活數(shù)量，根據(jù)存活數(shù)量確定各個需要進行恢復的副本的恢復優(yōu)先級。[0147]具體進行副本恢復時，需要將索引文件拷貝到目標檢索節(jié)點中，而在本申請實施例中，并不是從正在運行的其他檢索節(jié)點中進行拷貝，而是從Hadoop的HDFS文件系統(tǒng)中進行拷貝，也就是說，所述恢復單元具體可以包括:
[0148]全量索引拉取子單元，用于從存儲有所有檢索業(yè)務所需數(shù)據(jù)源及索引數(shù)據(jù)的文件系統(tǒng)中拉取最新的全量索引到所述目標檢索節(jié)點中。
[0149]另外，由于檢索節(jié)點上傳的信息可能存在延時，因此，在判斷是否存在需要恢復的副本的過程中，可能存在誤判，例如，可能在對一個副本執(zhí)行過恢復之后，原來的檢索節(jié)點才上傳上來關于該副本的信息，并且顯示該副本在該檢索節(jié)點中仍然處于存活狀態(tài)，則此時會出現(xiàn)多余副本的情況，失去M*N的結構，造成系統(tǒng)的不穩(wěn)定，為此，該系統(tǒng)還可以包括:
[0150]副本刪除單元，用于在將所述需要進行恢復的副本對應的索引文件拷貝到所述目標檢索節(jié)點中之后，根據(jù)各個檢索節(jié)點上傳的各個副本的當前狀態(tài)信息，查詢所述需要進行恢復的副本的當前存活數(shù)量，如果存活數(shù)量大于為對應檢索業(yè)務分配的副本數(shù)量，則將所述目標檢索節(jié)點中的該副本刪除。
[0151]總之,在本申請實施例中，可以抽象出一個中心節(jié)點CenterNode來實時掌控搜索平臺中所有檢索節(jié)點上的機器狀態(tài)，以及各個檢索節(jié)點上承載的所有業(yè)務的副本狀態(tài)，這樣，就可以根據(jù)這些狀態(tài)信息來確定是否存在需要進行恢復的副本，如果存在，還可以根據(jù)機器狀態(tài)信息以及副本的狀態(tài)信息，來綜合選擇出最合適的目標檢索節(jié)點，然后就可以在該節(jié)點上對副本進行恢復。可見，在本申請實施例中，在選擇用于進行副本恢復的目標檢索節(jié)點時，可以以各個檢索節(jié)點的機器狀態(tài)以及各個檢索節(jié)點中各個業(yè)務副本的狀態(tài)為依據(jù)，而不是進行隨機選擇，因此，可以在自動容災恢復過程中，更好地保證系統(tǒng)的穩(wěn)定性。
[0152]通過以上的實施方式的描述可知，本領域的技術人員可以清楚地了解到本申請可借助軟件加必需的通用硬件平臺的方式來實現(xiàn)?；谶@樣的理解，本申請的技術方案本質上或者說對現(xiàn)有技術做出貢獻的部分可以以軟件產(chǎn)品的形式體現(xiàn)出來，該計算機軟件產(chǎn)品可以存儲在存儲介質中，如R0M/RAM、磁碟、光盤等，包括若干指令用以使得一臺計算機設備(可以是個人計算機，服務器，或者網(wǎng)絡設備等)執(zhí)行本申請各個實施例或者實施例的某些部分所述的方法。
[0153]本說明書中的各個實施例均采用遞進的方式描述，各個實施例之間相同相似的部分互相參見即可，每個實施例重點說明的都是與其他實施例的不同之處。尤其，對于系統(tǒng)或系統(tǒng)實施例而言，由于其基本相似于方法實施例，所以描述得比較簡單，相關之處參見方法實施例的部分說明即可。以上所描述的系統(tǒng)及系統(tǒng)實施例僅僅是示意性的，其中所述作為分離部件說明的單元可以是或者也可以不是物理上分開的，作為單元顯示的部件可以是或者也可以不是物理單元，即可以位于一個地方，或者也可以分布到多個網(wǎng)絡單元上。可以根據(jù)實際的需要選擇其中的部分或者全部模塊來實現(xiàn)本實施例方案的目的。本領域普通技術人員在不付出創(chuàng)造性勞動的情況下，即可以理解并實施。
[0154]以上對本申請所提供的集群檢索平臺中的自動容災恢復方法及系統(tǒng)，進行了詳細介紹，本文中應用了具體個例對本申請的原理及實施方式進行了闡述，以上實施例的說明只是用于幫助理解本申請的方法及其核心思想；同時，對于本領域的一般技術人員，依據(jù)本申請的思想，在【具體實施方式】及應用范圍上均會有改變之處。綜上所述，本說明書內容不應理解為對本申請的限制。
【權利要求】
1.一種集群檢索平臺中的自動容災恢復方法，其特征在于，所述集群檢索平臺包括中心節(jié)點以及用于提供檢索服務的檢索節(jié)點，所述方法包括: 在所述中心節(jié)點中生成各個檢索節(jié)點的抽象，在所述檢索節(jié)點的抽象中創(chuàng)建關于該檢索節(jié)點的第一數(shù)據(jù)結構，并分別為該檢索節(jié)點承載的各個副本創(chuàng)建第二數(shù)據(jù)結構； 在所述第一動態(tài)信息數(shù)據(jù)結構中保存所述檢索節(jié)點上傳的當前機器狀態(tài)信息，在各個第二數(shù)據(jù)結構中保存所述檢索節(jié)點上傳的各個副本的當前狀態(tài)信息； 根據(jù)所述當前機器狀態(tài)信息和/或各個副本的當前狀態(tài)信息，判斷是否存在需要進行恢復的副本； 如果存在，則根據(jù)所述當前機器狀態(tài)信息以及各個副本的當前狀態(tài)信息，為所述需要進行恢復的副本選擇目標檢索節(jié)點； 將所述需要進行恢復的副本對應的索引文件拷貝到所述目標檢索節(jié)點中，由所述目標檢索節(jié)點根據(jù)所述索引文件提供檢索服務。
2.根據(jù)權利要求1所述的方法，其特征在于，所述當前機器狀態(tài)信息中保存有所述檢索節(jié)點上傳所述機器狀態(tài)信息時的最近更新時間信息，所述根據(jù)所述當前機器狀態(tài)信息和/或各個副本的當前狀態(tài)信息，判斷是否存在需要進行恢復的副本包括: 判斷所述最近更新時間是否小于當前時間與預置的安全時間間隔的差值，如果是，則確定所述檢索節(jié)點發(fā)生宕機，并將該檢索節(jié)點中承載的各個副本均確定為需要進行恢復的副本。
3.根據(jù)權利要求2所述的方法，其特征在于，在將所述需要進行恢復的副本對應的索引文件拷貝到所述目標檢索節(jié)點中之前，還包括: 根據(jù)各個檢索節(jié)點上傳的各個副本的當前狀態(tài)信息，查詢各個副本的當前存活數(shù)量，如果存活數(shù)量等于為對應檢索業(yè)務分配的副本數(shù)量，則取消對該檢索節(jié)點中承載的各個副本的恢復操作。
4.根據(jù)權利要求1所述的方法，其特征在于，所述根據(jù)所述當前機器狀態(tài)信息和/或各個副本的當前狀態(tài)信息，判斷是否存在需要進行恢復的副本包括: 根據(jù)所述各個副本的當前狀態(tài)信息，判斷某正常運行的檢索節(jié)點中是否存在不正常的副本，如果是，則將該不正常的副本確定為需要進行恢復的副本。
5.根據(jù)權利要求1所述的方法，其特征在于，所述根據(jù)所述當前機器狀態(tài)信息以及各個副本的當前狀態(tài)信息，為所述需要進行恢復的副本選擇目標檢索節(jié)點包括: 將標識為不能承載其他檢索業(yè)務的檢索節(jié)點、機器負載超出預置閾值的檢索節(jié)點、以及正在執(zhí)行副本恢復的檢索節(jié)點排除； 將剩余的檢索節(jié)點，從機器狀態(tài)維度以及副本狀態(tài)維度進行綜合排序，并根據(jù)排序結果確定目標檢索節(jié)點；其中，所述機器狀態(tài)維度包括磁盤剩余空間、可用內存、中央處理單元CPU核心的數(shù)量以及機器負載中的一種或多種，所述副本狀態(tài)維度包括當前檢索節(jié)點中承載的副本數(shù)量和/或每次請求時的平均響應時間。
6.根據(jù)權利要求5所述的方法，所述將剩余的檢索節(jié)點，從機器狀態(tài)維度以及副本狀態(tài)維度進行綜合排序包括: 對于承載的副本數(shù)量為O的檢索節(jié)點，磁盤剩余空間越大權重越高，磁盤剩余空間相等時，可用內存越大權重越聞；對于承載的副本數(shù)量不為O的檢索節(jié)點，則機器負載越小權重越高，機器負載相等時，承載的副本數(shù)量越少權重越高，承載的副本數(shù)量也相等時，每次請求時的平均響應時間越短權重越高。
7.根據(jù)權利要求1所述的方法，在將所述需要進行恢復的副本對應的索引文件拷貝到所述目標檢索節(jié)點中之前，還包括: 根據(jù)各個檢索節(jié)點上傳的各個副本的當前狀態(tài)信息，查詢各個需要進行恢復的副本的當前存活數(shù)量，根據(jù)存活數(shù)量確定各個需要進行恢復的副本的恢復優(yōu)先級。
8.根據(jù)權利要求1所述的方法，所述將所述需要進行恢復的副本對應的索引文件拷貝到所述目標檢索節(jié)點中包括: 從存儲有所有檢索業(yè)務所需數(shù)據(jù)源及索引數(shù)據(jù)的文件系統(tǒng)中拉取最新的全量索引到所述目標檢索節(jié)點中。
9.根據(jù)權利要求1所述的方法，在將所述需要進行恢復的副本對應的索引文件拷貝到所述目標檢索節(jié)點中之后，還包括: 根據(jù)各個檢索節(jié)點上傳的各個副本的當前狀態(tài)信息，查詢所述需要進行恢復的副本的當前存活數(shù)量，如果存活數(shù)量大于為對應檢索業(yè)務分配的副本數(shù)量，則將所述目標檢索節(jié)點中的該副本刪除。
10.一種集群檢 索平臺中的自動容災恢復系統(tǒng)，其特征在于，所述集群檢索平臺包括中心節(jié)點以及用于提供檢索服務的檢索節(jié)點，所述系統(tǒng)包括: 數(shù)據(jù)結構創(chuàng)建單元，用于在所述中心節(jié)點中生成各個檢索節(jié)點的抽象，在所述檢索節(jié)點的抽象中創(chuàng)建關于該檢索節(jié)點的第一數(shù)據(jù)結構，并分別為該檢索節(jié)點承載的各個副本創(chuàng)建第二數(shù)據(jù)結構； 信息保存單元，用于在所述第一動態(tài)信息數(shù)據(jù)結構中保存所述檢索節(jié)點上傳的當前機器狀態(tài)信息，在各個第二數(shù)據(jù)結構中保存所述檢索節(jié)點上傳的各個副本的當前狀態(tài)信息； 判斷單元，用于根據(jù)所述當前機器狀態(tài)信息和/或各個副本的當前狀態(tài)信息，判斷是否存在需要進行恢復的副本； 節(jié)點選擇單元，用于如果存在需要進行恢復的副本，則根據(jù)所述當前機器狀態(tài)信息以及各個副本的當前狀態(tài)信息，為所述需要進行恢復的副本選擇目標檢索節(jié)點； 恢復單元，用于將所述需要進行恢復的副本對應的索引文件拷貝到所述目標檢索節(jié)點中，由所述目標檢索節(jié)點根據(jù)所述索引文件提供檢索服務。
【文檔編號】G06F11/14GK104035836SQ201310071239
【公開日】2014年9月10日 申請日期:2013年3月6日 優(yōu)先權日:2013年3月6日
【發(fā)明者】柳明 申請人:阿里巴巴集團控股有限公司