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

李 政 武 彤

(貴州大學計算機科學與技術(shù)學院 貴州 貴陽 550025)

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

李 政 武 彤

(貴州大學計算機科學與技術(shù)學院 貴州 貴陽 550025)

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

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

0 引 言

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

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

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

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

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

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

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

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

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

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

1.1 分布式消息隊列

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

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

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

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

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

1.3 工作節(jié)點

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

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

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

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

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

2.1 全文索引的建立

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

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

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

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

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

圖2 全文索引過程

2.2 全文檢索的查詢算法

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

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

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

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

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

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

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

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

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

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

3 算法驗證

3.1 驗證環(huán)境

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

表1 宿主機硬件配置

表2 虛擬機計算資源

3.2 算法實現(xiàn)

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

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

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

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

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

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

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

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

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

4 結(jié) 語

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

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

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

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

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

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

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

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

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

[9] 鄭榕增,林世平.基于Lucene的中文倒排索引技術(shù)的研究[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