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

李 政 武 彤

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

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

李 政 武 彤

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

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

分布式消息隊列 企業級全文檢索 分布式全文檢索

0 引 言

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

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

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

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

本文在前述企業級全文檢索和相關分布式全文檢索方法的基礎上，結合分布式消息隊列技術，提出一種滿足企業級分布式全文檢索的模型。

1 總體結構

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

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

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

圖1 總體架構圖

1.1 分布式消息隊列

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

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

1.2 分布式協調器

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

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

1.3 工作節點

工作節點是整個系統中用于處理查詢請求以及接收用戶端請求的計算單元，每個節點對應著一個或多個上述檢索主題。也就是說，一個節點通常只處理一個或若干個主題的文檔，當建立索引時每個文檔根據不同的主題分發到相應節點上進行處理。在同一主題具有多個節點的情況下通過哈希算法將文檔均勻地分發給不同節點處理。同理查詢時根據用戶的權限不同，分發的查詢任務不會每個工作節點都進行接收處理。

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

2 分布式全文檢索過程設計

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

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

2.1 全文索引的建立

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

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

2) 文檔數據網關：按時從業務系統中根據需要抽取各類型文檔數據放入文檔數據隊列中；

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

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

圖2 全文索引過程

2.2 全文檢索的查詢算法

根據索引的分片結構，系統在響應用戶查詢的時候會根據權限方面的區別向不同的索引服務器發送查詢請求，最后根據各個服務器的響應結果集綜合排序后返回結果給用戶。

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

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

1) 用戶向系統發起查詢請求，經過負載均衡后用戶的請求轉發給某一臺工作節點，此節點作為臨時主節點。

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

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

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

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

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

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

3 算法驗證

3.1 驗證環境

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

表1 宿主機硬件配置

表2 虛擬機計算資源

3.2 算法實現

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

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

2) 使用Zookeeper部署了分布式協調器，提供分布式元數據管理以及分布式鎖功能；

3) 使用Lucene實現了分布式文檔索引引擎，對100GB的企業文檔數據進行索引；

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

通過算法的實現驗證了所提出模型的可行性。

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

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

圖3 并發性能測試

4 結 語

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

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

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

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

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

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

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

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

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

[9] 鄭榕增,林世平.基于Lucene的中文倒排索引技術的研究[J].計算機技術與發展,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。李政，碩士生，主研領域：數據庫技術，數據挖掘技術。武彤，教授。

TP311.133.1

A

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