李 政 武 彤

(貴州大學(xué)計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院 貴州 貴陽 550025)

基于分布式消息隊(duì)列的企業(yè)級全文檢索模型研究

李 政 武 彤

(貴州大學(xué)計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院 貴州 貴陽 550025)

針對傳統(tǒng)集中式全文檢索系統(tǒng)的查詢性能不足的問題，提出基于分布式消息隊(duì)列構(gòu)建的企業(yè)級分布式全文檢索模型。該模型充分利用分布式消息隊(duì)列將查詢集群中的各個節(jié)點(diǎn)去耦合，以異步方式對查詢請求進(jìn)行處理，提高整個集群的查詢吞吐量。從該模型的總體結(jié)構(gòu)、分布式全文檢索算法過程設(shè)計(jì)、算法驗(yàn)證三個方面進(jìn)行了闡述，驗(yàn)證了該模型的可行性，并且驗(yàn)證結(jié)果表明具有良好的查詢性能。

分布式消息隊(duì)列 企業(yè)級全文檢索 分布式全文檢索

0 引 言

隨著信息化技術(shù)的不斷發(fā)展，大、中型企業(yè)對信息化應(yīng)用的規(guī)模也在不斷擴(kuò)大，應(yīng)用的需求也越來越復(fù)雜。其中企業(yè)對各類文檔、報(bào)表數(shù)據(jù)的檢索需求從傳統(tǒng)的檢索方式發(fā)展為全文檢索的方式。而傳統(tǒng)的企業(yè)信息化平臺中只提供傳統(tǒng)的搜索功能甚至并沒有搜索功能，對全文檢索的應(yīng)用較少。

企業(yè)級全文檢索對檢索信息的整合性、安全性、準(zhǔn)確性都有較高的要求[1]，文檔來源多，雖然單一應(yīng)用系統(tǒng)中的文檔數(shù)量通常較少，但是對于整個企業(yè)的信息化平臺建設(shè)的全文檢索系統(tǒng)需要處理的文檔數(shù)量較多。若依據(jù)集中式方法建立全文檢索引擎，則在查詢效率上可能會不盡如人意。分布式技術(shù)是當(dāng)前處理大批量數(shù)據(jù)、復(fù)雜計(jì)算的流行方式，分布式全文檢索提出可以解決企業(yè)級全文檢索的索引建立和查詢的效率問題。

分布式全文檢索技術(shù)的引入提高了全文檢索系統(tǒng)在應(yīng)對大數(shù)據(jù)量查詢的性能以及全文檢索系統(tǒng)結(jié)構(gòu)的可擴(kuò)展性。分布式全文檢索的常用方式包括一種基于P2P的分布式搜索技術(shù)以及基于MapReduce的分布式搜索技術(shù)等[2]。P2P搜索技術(shù)中整個網(wǎng)絡(luò)中不存在中心節(jié)點(diǎn)，每一個節(jié)點(diǎn)都同時具有信息消費(fèi)者、信息提供者和信息通信三個方面的功能。基于MapReduce的分布式搜索技術(shù)的應(yīng)用就是傳統(tǒng)的集中式網(wǎng)絡(luò)服務(wù)，基于此技術(shù)的搜索引擎系統(tǒng)，擁有多個單搜索引擎，這些引擎分布在不同的地方，中心搜索引擎利用這些分布的、單個的搜索引擎的結(jié)果進(jìn)行整合得到完整的結(jié)果。元搜索引擎技術(shù)是一種基于搜索引擎的搜索引擎[3]，通過整合多個獨(dú)立的搜索引擎結(jié)果向用戶提供查詢結(jié)果。

分布式消息隊(duì)列作為一種重要的分布式系統(tǒng)通信方式已被當(dāng)前很多分布式系統(tǒng)的設(shè)計(jì)所采用。在文獻(xiàn)[4]中所提出的一種基于分布式消息隊(duì)列的通信方法的數(shù)據(jù)傳輸速率證實(shí)明顯優(yōu)于Socket方法。并且得益于消息隊(duì)列對消息生產(chǎn)者和消息消費(fèi)者之間的解耦，使得分布式系統(tǒng)的靈活性和容錯性大大提高，相應(yīng)地，整個系統(tǒng)所能承受的負(fù)載也會有所提升。同樣，消息隊(duì)列把分布式集群中各個節(jié)點(diǎn)的關(guān)系耦合度降低，使得這樣的結(jié)構(gòu)可以易于擴(kuò)展。那么如何將分布式消息隊(duì)列技術(shù)應(yīng)用在企業(yè)級分布式全文檢索中就成為了一個值得研究的問題。

本文在前述企業(yè)級全文檢索和相關(guān)分布式全文檢索方法的基礎(chǔ)上，結(jié)合分布式消息隊(duì)列技術(shù)，提出一種滿足企業(yè)級分布式全文檢索的模型。

1 總體結(jié)構(gòu)

由于企業(yè)級全文檢索對權(quán)限控制嚴(yán)格要求，結(jié)合元搜索引擎的思想，分布式全文檢索系統(tǒng)可以分為多個主題，這個主題一般是由人工設(shè)定的，例如財(cái)務(wù)、人事、生產(chǎn)、科研等。這里所述的主題與面向主題的搜索引擎[5]中的概念類似，整個系統(tǒng)可以人為設(shè)定或通過聚類算法對文檔進(jìn)行分主題管理，將數(shù)據(jù)量較大的文檔集合拆分為若干個不同主題的文檔集。系統(tǒng)針對每個主題都可以進(jìn)行權(quán)限控制，結(jié)合其他權(quán)限控制方式則可以實(shí)現(xiàn)企業(yè)級全文檢索嚴(yán)格的文檔資源訪問控制功能。

從邏輯結(jié)構(gòu)上來看，每個主題作為一個相對獨(dú)立的搜索接口分布在工作節(jié)點(diǎn)上，由至少一個工作節(jié)點(diǎn)來負(fù)責(zé)這個主題內(nèi)文檔的處理工作。各個工作節(jié)點(diǎn)之間的通信和事務(wù)處理分別通過分布式消息隊(duì)列和分布式協(xié)調(diào)器來實(shí)現(xiàn)。每一個工作節(jié)點(diǎn)同時具有處理用戶的查詢請求、響應(yīng)其他節(jié)點(diǎn)所提交的查詢、進(jìn)行文檔索引建立的功能，每個工作節(jié)點(diǎn)存儲有該節(jié)點(diǎn)對應(yīng)主題的索引分片數(shù)據(jù)。在查詢時不同索引節(jié)點(diǎn)上會產(chǎn)生不同的查詢結(jié)果，然后統(tǒng)一對這些結(jié)果集進(jìn)行合并得到最終查詢結(jié)果。

由上述結(jié)構(gòu)可以看出，整個系統(tǒng)以一種具有多入口的計(jì)算集群的方式提供服務(wù)，而通過負(fù)載均衡方式對外展示統(tǒng)一的接口。客戶機(jī)通過這個接口發(fā)送查詢請求經(jīng)過負(fù)載均衡均勻分布在集群內(nèi)各個工作節(jié)點(diǎn)上以提高系統(tǒng)效率。企業(yè)級全文檢索系統(tǒng)的總體結(jié)構(gòu)如圖1所示。

圖1 總體架構(gòu)圖

1.1 分布式消息隊(duì)列

分布式消息隊(duì)列是運(yùn)行在一組通過網(wǎng)絡(luò)連接的計(jì)算機(jī)集群上的軟件實(shí)體，其維護(hù)著一個或多個存儲消息的隊(duì)列，并且提供了對消息的發(fā)布或訂閱操作。使用消息隊(duì)列進(jìn)行通信的程序有時又稱為消息生產(chǎn)者或消息消費(fèi)者。分布式消息隊(duì)列將傳統(tǒng)用于進(jìn)程間通信的方式發(fā)展到了集群環(huán)境中。當(dāng)前分布式消息隊(duì)列的一個主要協(xié)議為高級消息隊(duì)列協(xié)議(AMQP)，其統(tǒng)一了消息模式，如發(fā)布/訂閱、隊(duì)列、事務(wù)以及流數(shù)據(jù)。該協(xié)議定義了通過網(wǎng)絡(luò)發(fā)送的字節(jié)流數(shù)據(jù)格式，所以任何實(shí)現(xiàn)了該協(xié)議的程序都可以進(jìn)行交互，做到跨語言、跨平臺[6]。AMQP中定義了消息的生產(chǎn)者、消息交換器、消息消費(fèi)者，消息交換器在中間起到了消息的路由以及消息存儲的功能，通過消息路由機(jī)制可以方便地控制不同主題消息的分發(fā)。

在該系統(tǒng)結(jié)構(gòu)中分布式消息隊(duì)列充當(dāng)集群中所有節(jié)點(diǎn)之間對等通信的橋梁，各個節(jié)點(diǎn)通過消息隊(duì)列發(fā)布查詢請求、查詢結(jié)果以及接收查詢請求。一般分布式消息隊(duì)列的消息發(fā)布分為同步消息和異步消息兩種方式。同步消息方式情況下，消息生產(chǎn)者發(fā)布消息后需要等待消息消費(fèi)者的響應(yīng)才能完成一次消息通信過程，異步消息方式情況下消息生產(chǎn)者只負(fù)責(zé)把消息推送至分布式消息隊(duì)列中，而不需要等待消息消費(fèi)者的響應(yīng)。在分布式全文檢索的查詢過程中使用異步消息模式，各索引節(jié)點(diǎn)可以同時進(jìn)行某一查詢請求的處理，這樣對于整個系統(tǒng)的吞吐量有更大提高。

1.2 分布式協(xié)調(diào)器

分布式系統(tǒng)需要一個主控制節(jié)點(diǎn)管理集群內(nèi)各個工作節(jié)點(diǎn)的事務(wù)處理，保證集群內(nèi)數(shù)據(jù)的一致性。分布式協(xié)調(diào)器可以在一個所有節(jié)點(diǎn)對等的集群上實(shí)現(xiàn)：① 各節(jié)點(diǎn)數(shù)據(jù)一致性，提供分布式鎖服務(wù)；② 在部分節(jié)點(diǎn)失效的情況下提供服務(wù)的能力；③ 實(shí)時監(jiān)測節(jié)點(diǎn)情況，處理節(jié)點(diǎn)失效、連接超時、鏈接失效等異常。在分布式系統(tǒng)中保證以上三點(diǎn)非常重要，同時不能由于協(xié)調(diào)器的性能問題對分布式集群的性能有過大影響。Zookeeper是Google的Chubby的一個開源實(shí)現(xiàn)，其為分布式系統(tǒng)提供了一個高效的數(shù)據(jù)一致性解決方法，并且基于Zookeeper可以實(shí)現(xiàn)分布式系統(tǒng)鎖功能[7]，在此基礎(chǔ)上實(shí)現(xiàn)分布式事務(wù)等功能。

分布式協(xié)調(diào)器管理著整個集群的元數(shù)據(jù)，并且保證其一致性，可以在數(shù)據(jù)變化時通知相關(guān)節(jié)點(diǎn)。分布式全文檢索中的各個工作節(jié)點(diǎn)需要在協(xié)調(diào)器中注冊一個對應(yīng)自己的臨時數(shù)據(jù)節(jié)點(diǎn)。利用協(xié)調(diào)器在客戶端會話中斷時自動刪除臨時數(shù)據(jù)節(jié)點(diǎn)的特性來實(shí)時監(jiān)控處理工作節(jié)點(diǎn)的失效問題。在某一節(jié)點(diǎn)失效的情況下，該節(jié)點(diǎn)在協(xié)調(diào)器中的元數(shù)據(jù)中一個臨時節(jié)點(diǎn)會被刪除，協(xié)調(diào)器會立即通知正在等待響應(yīng)的節(jié)點(diǎn)，已發(fā)送的查詢請求可以實(shí)時取消，新來的查詢請求不再包含失效的節(jié)點(diǎn)。若是在索引建立的時刻某節(jié)點(diǎn)失效，可以依據(jù)兩種策略進(jìn)行處理，一種是取消該次索引建立，另一種是在消息隊(duì)列中保存索引建立的消息，待失效節(jié)點(diǎn)恢復(fù)工作后還可以從之前的消息隊(duì)列位置開始處理數(shù)據(jù)。

1.3 工作節(jié)點(diǎn)

工作節(jié)點(diǎn)是整個系統(tǒng)中用于處理查詢請求以及接收用戶端請求的計(jì)算單元，每個節(jié)點(diǎn)對應(yīng)著一個或多個上述檢索主題。也就是說，一個節(jié)點(diǎn)通常只處理一個或若干個主題的文檔，當(dāng)建立索引時每個文檔根據(jù)不同的主題分發(fā)到相應(yīng)節(jié)點(diǎn)上進(jìn)行處理。在同一主題具有多個節(jié)點(diǎn)的情況下通過哈希算法將文檔均勻地分發(fā)給不同節(jié)點(diǎn)處理。同理查詢時根據(jù)用戶的權(quán)限不同，分發(fā)的查詢?nèi)蝿?wù)不會每個工作節(jié)點(diǎn)都進(jìn)行接收處理。

工作節(jié)點(diǎn)中可以采用Lucene作為處理全文檢索索引以及查詢的基礎(chǔ)組件，Lucene具有索引查詢效率高，功能強(qiáng)大等特點(diǎn)，并且支持全文檢索的查詢模型，例如布爾表達(dá)式查詢。Lucene的主要組成部分包括分詞模塊(Analysis)、索引模塊(Index)和檢索模塊(Search)[8]。分詞模塊作為文檔數(shù)據(jù)的預(yù)處理組件，具有良好的擴(kuò)展性，可以方便地使用不同的分詞引擎，實(shí)現(xiàn)分詞結(jié)果的優(yōu)化。索引模塊提供了增量索引和批量索引的功能，并且支持近實(shí)時搜索，在索引真正寫入文件之前即可提供查詢功能。檢索模塊是真正提供查詢功能的部分，其不局限于文本查詢，還支持復(fù)雜的表達(dá)式查詢功能，可以根據(jù)用戶構(gòu)建的檢索模型表達(dá)式樹進(jìn)行快速的查詢。

2 分布式全文檢索過程設(shè)計(jì)

全文檢索系統(tǒng)主要包括兩個過程：一是索引建立過程，二是查詢過程。企業(yè)級全文檢索系統(tǒng)中文檔來源于企業(yè)中的各個業(yè)務(wù)應(yīng)用系統(tǒng)，各個業(yè)務(wù)系統(tǒng)中包含數(shù)據(jù)庫數(shù)據(jù)、文本數(shù)據(jù)、半結(jié)構(gòu)化表格數(shù)據(jù)等，文檔類型繁多，所以需要考慮文檔索引的存儲，設(shè)計(jì)出高效的索引建立以及查詢方法。

傳統(tǒng)集中式全文檢索的索引建立方式比較單一，一般是通過單個接口進(jìn)行文檔的獲取和索引建立工作，在效率上會有性能瓶頸。且隨著文檔數(shù)量的增多，集中式的方式擴(kuò)展性上也會出現(xiàn)很大問題。而分布式全文檢索中可以采用更加靈活的調(diào)度方式對文檔數(shù)據(jù)進(jìn)行分發(fā)處理，也很容易通過增加節(jié)點(diǎn)的方式進(jìn)行系統(tǒng)的橫向擴(kuò)展。

2.1 全文索引的建立

本文所述分布式全文索引的結(jié)構(gòu)是根據(jù)主題進(jìn)行分片，來源于企業(yè)各個應(yīng)用系統(tǒng)的文檔資源通常自然地對應(yīng)了相應(yīng)主題。這樣的索引分片方法其實(shí)屬于基于文檔的分割方法，每個工作節(jié)點(diǎn)上的索引分片相對獨(dú)立，通過哈希算法將文檔分布在對應(yīng)主題的多個索引節(jié)點(diǎn)中。全文索引的建立主要包括的組件有：

1) 文檔數(shù)據(jù)隊(duì)列：用于存放待索引的文檔信息，隊(duì)列以主題劃分，通過消息路由分發(fā)不同主題的文檔數(shù)據(jù)，負(fù)責(zé)不同主題的工作節(jié)點(diǎn)在文檔工作隊(duì)列中獲取文檔信息進(jìn)行索引建立；

2) 文檔數(shù)據(jù)網(wǎng)關(guān)：按時從業(yè)務(wù)系統(tǒng)中根據(jù)需要抽取各類型文檔數(shù)據(jù)放入文檔數(shù)據(jù)隊(duì)列中；

3) 文檔索引引擎：分布在各個工作節(jié)點(diǎn)上運(yùn)行的進(jìn)程，監(jiān)聽文檔數(shù)據(jù)隊(duì)列，在有新的文檔操作消息到來時進(jìn)行相應(yīng)的索引建立、索引更新、索引刪除操作，在索引節(jié)點(diǎn)中采用Lucene實(shí)現(xiàn)基本索引功能，將文檔進(jìn)行文本分詞后建立索引文件進(jìn)行存儲。

全文索引建立結(jié)構(gòu)如圖2所示，根據(jù)這一索引建立結(jié)構(gòu)，可以有效地管理文檔索引建立的過程，異步化的方式減小了發(fā)生故障的影響。在節(jié)點(diǎn)索引建立方面目前最流行的辦法是以文檔分詞后的詞語作為索引項(xiàng)進(jìn)行倒排索引，查詢時通過詞向量相似度計(jì)算算法來獲取以相關(guān)程度排序的查詢結(jié)果。如一種基于Lucene實(shí)現(xiàn)的采用正相最大匹配分詞算法的索引技術(shù)[9]，可以快速對文檔進(jìn)行分詞并建立索引。索引建立后的文件持久化存儲在工作節(jié)點(diǎn)上提供查詢請求。

圖2 全文索引過程

2.2 全文檢索的查詢算法

根據(jù)索引的分片結(jié)構(gòu)，系統(tǒng)在響應(yīng)用戶查詢的時候會根據(jù)權(quán)限方面的區(qū)別向不同的索引服務(wù)器發(fā)送查詢請求，最后根據(jù)各個服務(wù)器的響應(yīng)結(jié)果集綜合排序后返回結(jié)果給用戶。

在響應(yīng)用戶查詢的方式上傳統(tǒng)的分布式全文檢索需要一個主節(jié)點(diǎn)去進(jìn)行處理，這樣的結(jié)構(gòu)會導(dǎo)致主節(jié)點(diǎn)的負(fù)載過高，不利于分布式集群的擴(kuò)展，在本文所述的結(jié)構(gòu)中每一個工作節(jié)點(diǎn)都可以響應(yīng)查詢。

具體的全文檢索查詢算法流程如下：

1) 用戶向系統(tǒng)發(fā)起查詢請求，經(jīng)過負(fù)載均衡后用戶的請求轉(zhuǎn)發(fā)給某一臺工作節(jié)點(diǎn)，此節(jié)點(diǎn)作為臨時主節(jié)點(diǎn)。

2) 臨時主節(jié)點(diǎn)接收到查詢請求，對此次查詢生成一個全局唯一的查詢Id，在分布式消息隊(duì)列中新建以此查詢Id為Key的消息隊(duì)列。

3) 臨時主節(jié)點(diǎn)驗(yàn)證查詢請求中用戶的權(quán)限信息，向滿足權(quán)限的查詢主題消息隊(duì)列中添加含有查詢Id以及查詢請求內(nèi)容的消息。

4) 臨時主節(jié)點(diǎn)在分布式協(xié)調(diào)器中注冊以查詢Id為名稱的數(shù)據(jù)節(jié)點(diǎn)，并在該數(shù)據(jù)節(jié)點(diǎn)下添加各主題對應(yīng)名字的數(shù)據(jù)節(jié)點(diǎn)用于標(biāo)識某個主題的查詢是否已經(jīng)成功響應(yīng)，然后監(jiān)聽各個主題對應(yīng)數(shù)據(jù)節(jié)點(diǎn)的修改事件。

5) 索引節(jié)點(diǎn)通過監(jiān)聽自己所負(fù)責(zé)的主題隊(duì)列可以及時獲取到臨時主節(jié)點(diǎn)添加的查詢請求，索引節(jié)點(diǎn)立即根據(jù)線程池的情況分配或新建一個線程對這個查詢進(jìn)行處理。

6) 索引節(jié)點(diǎn)的一個線程通過索引引擎獲取滿足查詢的結(jié)果列表，然后將該結(jié)果列表序列化后發(fā)送到與查詢Id相對應(yīng)的消息隊(duì)列中，形成多個結(jié)果集R1,R2,…,RN。最后在分布式協(xié)調(diào)器中將查詢Id對應(yīng)的數(shù)據(jù)節(jié)點(diǎn)下的主題數(shù)據(jù)節(jié)點(diǎn)標(biāo)識設(shè)置為已完成。

7) 臨時主節(jié)點(diǎn)在所有節(jié)點(diǎn)查詢完成或者響應(yīng)超時的情況下將查詢Id相對應(yīng)的消息隊(duì)列中結(jié)果集合并后發(fā)送給用戶，完成一次查詢請求。

3 算法驗(yàn)證

3.1 驗(yàn)證環(huán)境

對于本文研究算法的驗(yàn)證，采用的驗(yàn)證環(huán)境是基于虛擬化平臺的3臺虛擬化集群，其中宿主機(jī)和虛擬機(jī)的配置分別如下表1、表2所示。

表1 宿主機(jī)硬件配置

表2 虛擬機(jī)計(jì)算資源

3.2 算法實(shí)現(xiàn)

根據(jù)本文所述的分布式全文檢索模型以及全文檢索查詢算法流程，算法實(shí)現(xiàn)階段包括以下工作：

1) 使用RabbitMQ部署分布式消息隊(duì)列集群，提供分布式消息隊(duì)列服務(wù)；

2) 使用Zookeeper部署了分布式協(xié)調(diào)器，提供分布式元數(shù)據(jù)管理以及分布式鎖功能；

3) 使用Lucene實(shí)現(xiàn)了分布式文檔索引引擎，對100GB的企業(yè)文檔數(shù)據(jù)進(jìn)行索引；

4) 結(jié)合全文檢索算法流程，使用Lucene提供基礎(chǔ)索引操作功能以及RabbitMQ客戶端和Zookeeper客戶端實(shí)現(xiàn)了工作節(jié)點(diǎn)的功能。

通過算法的實(shí)現(xiàn)驗(yàn)證了所提出模型的可行性。

為了與本文所提出的模型進(jìn)行對比，采用Lucene實(shí)現(xiàn)了一個集中式全文檢索服務(wù)，以單服務(wù)器形式部署，同樣對100GB的文檔進(jìn)行了索引。

在此基礎(chǔ)上進(jìn)行了集群的性能測試，主要測試分布式全文檢索的并發(fā)查詢性能，分別測試了500至10 000并發(fā)請求量下的響應(yīng)時間。圖3為該模型在不同查詢并發(fā)數(shù)下與集中式全文檢索的平均響應(yīng)時間對比。通過性能測試可以看出分布式全文檢索在并發(fā)請求數(shù)上升的情況下也可以保持較為平緩的響應(yīng)時間增長。

圖3 并發(fā)性能測試

4 結(jié) 語

當(dāng)前全文檢索技術(shù)在企業(yè)信息化平臺中的應(yīng)用相對較少，并且企業(yè)信息化平臺中的大量文檔數(shù)據(jù)來源以及企業(yè)級全文檢索對整合性、安全性、準(zhǔn)確性以及查詢性能的要求，促使企業(yè)級全文檢索向分布式方向發(fā)展。分布式全文檢索系統(tǒng)相較于集中式全文檢索系統(tǒng)具有吞吐量大、易擴(kuò)展等特點(diǎn)，本文提出了基于分布式消息隊(duì)列構(gòu)建的企業(yè)級分布式全文檢索模型。該模型利用分布式消息隊(duì)列將查詢集群中的各個工作節(jié)點(diǎn)之間的關(guān)系松耦合化，以異步處理的方式對查詢請求進(jìn)行處理，通過驗(yàn)證，該模型可以提高整個集群的查詢吞吐量。

[1] 武駿,王雅娜,趙剛,等.企業(yè)級搜索的技術(shù)特征分析[C]//第二十一屆全國計(jì)算機(jī)信息管理學(xué)術(shù)研討會,2007.銀川:中國科學(xué)技術(shù)情報(bào)學(xué)會,2007:79-83.

[2] 蔣建洪.主要分布式搜索引擎技術(shù)的研究[J].科學(xué)技術(shù)與工程,2007,7(10):2418-2424.

[3] 李廣建,黃崑.元搜索引擎及其主要技術(shù)[J].情報(bào)科學(xué),2002,20(2):175-179.

[4] 薛鵬飛,胡榮貴,胡勁松.基于ZeroMQ的分布式系統(tǒng)通信方法[J].計(jì)算機(jī)應(yīng)用,2015,35(S2):34-37.

[5] 姜華.基于Lucene面向主題搜索引擎的研究與設(shè)計(jì)[D].上海:華東師范大學(xué),2007.

[6] 吳煒鑫,王宇,王興偉,等.基于AMQP的校園消息總線系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[J].通信學(xué)報(bào),2013,34(Z2):180-183.

[7] 劉芬,王芳,田昊.基于Zookeeper的分布式鎖服務(wù)及性能優(yōu)化[J].計(jì)算機(jī)研究與發(fā)展,2014(S1):229-234.

[8] 李永春,丁華福.Lucene的全文檢索的研究與應(yīng)用[J].計(jì)算機(jī)技術(shù)與發(fā)展,2010,20(2):12-15.

[9] 鄭榕增,林世平.基于Lucene的中文倒排索引技術(shù)的研究[J].計(jì)算機(jī)技術(shù)與發(fā)展,2010,20(3):80-83.

RESEARCH ON ENTERPRISE FULL-TEXT RETRIEVAL MODEL BASED ON DISTRIBUTED MESSAGE QUEUE

Li Zheng Wu Tong

(SchoolofComputerScienceandTechnology,GuizhouUniversity,Guiyang550025,Guizhou,China)

Aiming at the problem of insufficient query performance of traditional centralized full-text retrieval system, this paper proposes a distributed enterprise full-text retrieval model based on distributed message queue construction. The model makes full use of the distributed message queue to couple each node in the query cluster to process the query request in an asynchronous way, and to improve the throughput of the whole cluster. We elaborate the feasibility of the model from three aspects: the overall structure, distributed full-text retrieval algorithm design process, algorithm verification, and the validation results show that it has a good query performance.

Distributed message queue Enterprise full-text retrieval Distributed full-text retrieval

2016-08-17。李政，碩士生，主研領(lǐng)域：數(shù)據(jù)庫技術(shù)，數(shù)據(jù)挖掘技術(shù)。武彤，教授。

TP311.133.1

A

10.3969/j.issn.1000-386x.2017.06.052