| 2007 年 11 月 27 日 為應(yīng)用程序添加搜索能力經(jīng)常是一個常見的需求。本文介紹了一個框架，開發(fā)者可以使用它以最小的付出實(shí)現(xiàn)搜索引擎功能，理想情況下只需要一個配置文件。該框 架基于若干開源的庫和工具，如 Apache Lucene，Spring 框架，cpdetector 等。它支持多種資源。其中兩個典型的例子是數(shù)據(jù)庫資源和文件系統(tǒng)資源。Indexer 對配置的資源進(jìn)行索引并傳輸?shù)街醒敕?wù)器，之后這些索引可以通過 API 進(jìn)行搜索。Spring 風(fēng)格的配置文件允許清晰靈活的自定義和調(diào)整。核心 API 也提供了可擴(kuò)展的接口。 引言 為 應(yīng)用程序添加搜索能力經(jīng)常是一個常見的需求。盡管已經(jīng)有若干程序庫提供了對搜索基礎(chǔ)設(shè)施的支持，然而對于很多人而言，使用它們從頭開始建立一個搜索引擎將 是一個付出不小而且可能乏味的過程。另一方面，很多的小型應(yīng)用對于搜索功能的需求和應(yīng)用場景具有很大的相似性。本文試圖以對多數(shù)小型應(yīng)用的適用性為出發(fā) 點(diǎn)，用 Java 語言構(gòu)建一個靈活的搜索引擎框架。使用這個框架，多數(shù)情形下可以以最小的付出建立起一個搜索引擎。最理想的情況下，甚至只需要一個配置文件。特殊的情形 下，可以通過靈活地對框架進(jìn)行擴(kuò)展?jié)M足需求。當(dāng)然，如題所述，這都是借助開源工具的力量。
基礎(chǔ)知識 Apache Lucene 是開發(fā)搜索類應(yīng)用程序時最常用的 Java 類庫，我們的框架也將基于它。為了下文更好的描述，我們需要先了解一些有關(guān) Lucene 和搜索的基礎(chǔ)知識。注意，本文不關(guān)注索引的文件格式、分詞技術(shù)等話題。 什么是搜索和索引 從 用戶的角度來看，搜索的過程是通過關(guān)鍵字在某種資源中尋找特定的內(nèi)容的過程。而從計(jì)算機(jī)的角度來看，實(shí)現(xiàn)這個過程可以有兩種辦法。一是對所有資源逐個與關(guān) 鍵字匹配，返回所有滿足匹配的內(nèi)容；二是如同字典一樣事先建立一個對應(yīng)表，把關(guān)鍵字與資源的內(nèi)容對應(yīng)起來，搜索時直接查找這個表即可。顯而易見，第二個辦 法效率要高得多。建立這個對應(yīng)表事實(shí)上就是建立逆向索引（inverted index）的過程。 Lucene 基本概念 Lucene 是 Doug Cutting 用 Java 開發(fā)的用于全文搜索的工具庫。在這里，我假設(shè)讀者對其已有基本的了解，我們只對一些重要的概念簡要介紹。要深入了解可以參考 參考資源 中列出的相關(guān)文章和圖書。下面這些是 Lucene 里比較重要的類。 -
Document：索引包含多個 Document。而每個 Document 則包含多個 Field 對象。Document 可以是從數(shù)據(jù)庫表里取出的一堆數(shù)據(jù)，可以是一個文件，也可以是一個網(wǎng)頁等。注意，它不等同于文件系統(tǒng)中的文件。 -
Field：一個 Field 有一個名稱，它對應(yīng) Document的一部分?jǐn)?shù)據(jù)，表示文檔的內(nèi)容或者文檔的元數(shù)據(jù)（與下文中提到的資源元數(shù)據(jù)不是一個概念）。一個 Field 對象有兩個重要屬性：Store ( 可以有 YES, NO, COMPACT 三種取值 ) 和 Index ( 可以有 TOKENIZED, UN_TOKENIZED, NO, NO_NORMS 四種取值 ) -
Query：抽象了搜索時使用的語句。 -
IndexSearcher：提供 Query 對象給它，它利用已有的索引進(jìn)行搜索并返回搜索結(jié)果。 -
Hits：一個容器，包含了指向一部分搜索結(jié)果的指針。 使用 Lucene 來進(jìn)行編制索引的過程大致為：將輸入的數(shù)據(jù)源統(tǒng)一為字符串或者文本流的形式，然后從數(shù)據(jù)源提取數(shù)據(jù)，創(chuàng)建合適的 Field 添加到對應(yīng)數(shù)據(jù)源的 Document 對象之中。
系統(tǒng)概覽 要 建立一個通用的框架，必須對不同情況的共性進(jìn)行抽象。反映到設(shè)計(jì)需要注意兩點(diǎn)。一是要提供擴(kuò)展接口；二是要盡量降低模塊之間的耦合程度。我們的框架很簡單 地分為兩個模塊：索引模塊和搜索模塊。索引模塊在不同的機(jī)器上各自進(jìn)行對資源的索引，并把索引文件（事實(shí)上，下面我們會說到，還有元數(shù)據(jù)）統(tǒng)一傳輸?shù)酵?個地方（可以是在遠(yuǎn)程服務(wù)器上，也可以是在本地）。搜索模塊則利用這些從多個索引模塊收集到的數(shù)據(jù)完成用戶的搜索請求。 圖 1 展現(xiàn)了整體的框架。可以看到，兩個模塊之間相對是獨(dú)立的，它們之間的關(guān)聯(lián)不是通過代碼，而是通過索引和元數(shù)據(jù)。在下文中，我們將會詳細(xì)介紹如何基于開源工具設(shè)計(jì)和實(shí)現(xiàn)這兩個模塊。
圖 1. 系統(tǒng)架構(gòu)圖
建立索引 可以進(jìn)行索引的對象有很多，如文件、網(wǎng)頁、RSS Feed 等。在我們的框架中，我們定義可以進(jìn)行索引的一類對象為資源。從實(shí)現(xiàn)細(xì)節(jié)上來說，從一個資源中可以提取出多個 Document 對象。文件系統(tǒng)資源和數(shù)據(jù)庫結(jié)果集資源都是資源的代表性例子。 前面提到，從資源中收集到的索引被統(tǒng)一傳送到同一個地方，以被搜索模塊所用。顯然除了索引之外，搜索模塊需要對資源有更多的了解，如資源的名稱、搜索該資源后搜索結(jié)果的呈現(xiàn)格式等。這些額外的附加信息稱為資源的元數(shù)據(jù)。元數(shù)據(jù)和索引數(shù)據(jù)一同被收集起來，放置到某個特定的位置。 簡要地介紹過資源的概念之后，我們首先為其定義一個 Resource 接口。這個接口的聲明如下。
清單 1. Resource 接口
public interface Resource {
// RequestProcessor 對象被動地從資源中提取 Document，并返回提取的數(shù)量
public int extractDocuments(ResourceProcessor processor);
// 添加的 DocumentListener 將在每一個 Document 對象被提取出時被調(diào)用
public void addDocumentListener(DocumentListener l);
// 返回資源的元數(shù)據(jù)
public ResourceMetaData getMetaData();
} |
其中元數(shù)據(jù)包含的字段見下表。在下文中，我們還會對元數(shù)據(jù)的用途做更多的介紹。
表 1. 資源元數(shù)據(jù)包含的字段
而 DocumentListener 的代碼如下。
清單 2. DocumentListener 接口
public interface DocumentListener extends EventListener {
public void documentExtracted(Document doc);
}
|
為了讓索引模塊能夠知道所有需要被索引的資源，我們在這里使用 Spring 風(fēng)格的 XML 文件配置索引模塊中的所有組件，尤其是所有資源。您可以在 下載部分 查看一個示例配置文件。 | 為什么選擇使用 Spring 風(fēng)格的配置文件？
這主要有兩個好處： - 僅依賴于 Spring Core 和 Spring Beans 便免去了定義配置機(jī)制和解析配置文件的負(fù)擔(dān)；
- Spring 的 IoC 機(jī)制降低了框架的耦合性，并使擴(kuò)展框架變得簡單；
| | 基于以上內(nèi)容，我們可以大致描述出索引模塊工作的過程： - 首先在 XML 配置的 bean 中找出所有
Resource 對象； - 對每一個調(diào)用其
extractDocuments() 方法，這一步除了完成對資源的索引外，還會在每次提取出一個 Document 對象之后，通知注冊在該資源上的所有 DocumentListener； - 接著處理資源的元數(shù)據(jù)（
getMetaData() 的返回值）； - 將緩存里的數(shù)據(jù)寫入到本地磁盤或者傳送給遠(yuǎn)程服務(wù)器；
在這個過程中，有兩個地方值得注意。 第一，對資源可以注冊 DocumentListener 使得我們可以在運(yùn)行時刻對索引過程有更為動態(tài)的控制。舉一個簡單例子，對某個文章發(fā)布站點(diǎn)的文章進(jìn)行索引時，一個很正常的要求便是發(fā)布時間更靠近當(dāng)前時間的文章需要在搜索結(jié)果中排在靠前的位置。每篇文章顯然對應(yīng)一個 Document 對象，在 Lucene 中我們可以通過設(shè)置 Document 的 boost 值來對其進(jìn)行加權(quán)。假設(shè)其中文章發(fā)布時間的 Field 的名稱為 PUB_TIME，那么我們可以為資源注冊一個 DocumentListener，當(dāng)它被通知時，則檢測 PUB_TIME 的值，根據(jù)距離當(dāng)前時間的遠(yuǎn)近進(jìn)行加權(quán)。 第二點(diǎn)很顯然，在這個過程中，extractDocuments() 方法的實(shí)現(xiàn)依不同類型的資源而各異。下面我們主要討論兩種類型的資源：文件系統(tǒng)資源和數(shù)據(jù)庫結(jié)果集資源。這兩個類都實(shí)現(xiàn)了上面的 接口。 文件系統(tǒng)資源 對文件系統(tǒng)資源的索引通常從一個基目錄開始，遞歸處理每個需要進(jìn)行索引的文件。該資源有一個字符串?dāng)?shù)組類型的 excludedFiles 屬性，表示在處理文件時需要排除的文件絕對路徑的正則表達(dá)式。在遞歸遍歷文件系統(tǒng)樹的同時，絕對路徑匹配 excludedFiles 中任意一項(xiàng)的文件將不會被處理。這主要是考慮到一般我們只需要對一部分文件夾（比如排除可能存在的備份目錄）中的一部分文件（如 doc, ppt 文件等）進(jìn)行索引。 除了所有文件共有的文件名、文件路徑、文件大小和修改時間等 Field，不同類型的文件需要有不同的處理方法。為了保留靈活性，我們使用 Strategy 模式封裝對不同類型文件的處理方式。為此我們抽象出一個 DocumentBuilder 的接口，該接口僅定義了一個方法如下：
清單 3. DocumentBuilder 接口
public interface DocumentBuilder {
Document buildDocument(InputStream is);
} |
| 什么是 Strategy 模式？
根 據(jù) Design patterns: Elements of reusable object orientated software 一書：Strategy 模式“定義一系列的算法，把它們分別封裝起來，并且使它們相互可以替換。這個模式使得算法可以獨(dú)立于使用它的客戶而變化?！?/p> | | 不同的 DocumentBuilder（Strategy） 用于從一個輸入流中讀取數(shù)據(jù)，處理不同類型的文件。對于常見的文件格式來說，都有合適的開源工具幫助進(jìn)行解析。在下表中我們列舉一些常見文件類型的解析辦法。 | 文件類型 | 常用擴(kuò)展名 | 可以使用的解析辦法 | | 純文本文檔 | txt | 無需類庫解析 | | RTF 文檔 | rtf | 使用 javax.swing.text.rtf.RTFEditorKit 類 | | Word 文檔（非 OOXML 格式） | doc | Apache POI （可配合使用 POI Scratchpad） | | PowerPoint 演示文稿（非 OOXML 格式） | xls | Apache POI （可配合使用 POI Scratchpad） | | PDF 文檔 | pdf | PDFBox（可能中文支持欠佳） | | HTML 文檔 | htm, html | JTidy, Cobra | 這里以 Word 文件為例，給出一個簡單的參考實(shí)現(xiàn)。
清單 4. 解析純文本內(nèi)容的實(shí)現(xiàn)
// WordDocument 是 Apache POI Scratchpad 中的一個類
Document buildDocument(InputStream is) {
String bodyText = null;
try {
WordDocument wordDoc = new WordDocument(is);
StringWriter sw = new StringWriter();
wordDoc.writeAllText(sw);
sw.close();
bodyText = sw.toString();
} catch (Exception e) {
throw new DocumentHandlerException("Cannot extract text from a Word document", e);
}
if ((bodyText != null) && (bodyText.trim().length() > 0)) {
Document doc = new Document();
doc.add(new Field("body", bodyText, Field.Store.YES, Field.Index.TOKENIZED));
return doc;
}
return null;
}
|
那么如何選擇合適的 Strategy 來處理文件呢？UNIX 系統(tǒng)下的 file(1) 工具提供了從 magicnumber 獲取文件類型的功能，我們可以使用 Runtime.exec() 方法調(diào)用這一命令。但這需要在有 file(1) 命令的情況下，而且并不能識別出所有文件類型。在一般的情況下我們可以簡單地根據(jù)擴(kuò)展名來使用合適的類處理文件。擴(kuò)展名和類的映射關(guān)系寫在 properties 文件中。當(dāng)需要添加對新的文件類型的支持時，我們只需添加一個新的實(shí)現(xiàn) DocumentBuilder 接口的類，并在映射文件中添加一個映射關(guān)系即可。 數(shù)據(jù)庫結(jié)果集資源 大多數(shù)應(yīng)用使用數(shù)據(jù)庫作為永久存儲，對數(shù)據(jù)庫查詢結(jié)果集索引是一個常見需求。 生成一個數(shù)據(jù)庫結(jié)果集資源的實(shí)例需要先提供一個查詢語句，然后執(zhí)行查詢，得到一個結(jié)果集。這個結(jié)果集中的內(nèi)容便是我們需要進(jìn)行索引的對象。extractDocuments 的實(shí)現(xiàn)便是為結(jié)果集中的每一行創(chuàng)建一個 Document 對象。和文件系統(tǒng)資源不同的是，數(shù)據(jù)庫資源需要放入 Document 中的 Field 一般都存在在查詢結(jié)果集之中。比如一個簡單的文章發(fā)布站點(diǎn)，對其后臺數(shù)據(jù)庫執(zhí)行查詢 SELECT ID, TITLE, CONTENT FROM ARTICLE 返回一個有三列的結(jié)果集。對結(jié)果集的每一行都會被提取出一個 Document 對象，其中包含三個 Field，分別對應(yīng)這三列。 然而不同 Field 的類型是不同的。比如 ID 字段一般對應(yīng) Store.YES 和 Index.NO 的 Field；而 TITLE 字段則一般對應(yīng) Store.YES 和 Index.TOKENIZED 的 Field。為了解決這個問題，我們在數(shù)據(jù)庫結(jié)果集資源的實(shí)現(xiàn)中提供一個類型為 Properties 的 fieldTypeMappings 屬性，用于設(shè)置數(shù)據(jù)庫字段所對應(yīng)的 Field 的類型。對于前面的情況來說，這個屬性可能會被配置成類似這樣的形式： ID = YES, NO
TITLE = YES, TOKENIZED
CONTENT = NO, TOKENIZED |
配合這個映射，我們便可以生成合適類型的 Field，完成對結(jié)果集索引的工作。
收集索引 完成對資源的索引之后，還需要讓索引為搜索模塊所用。前面我們已經(jīng)說過這里介紹的框架主要用于小型應(yīng)用，考慮到復(fù)雜性，我們采取簡單地將分布在各個機(jī)器上的索引匯總到一個地方的策略。 匯總索引的傳輸方式可以有很多方案，比如使用 FTP、HTTP、rsync 等。甚至索引模塊和搜索模塊可以位于同一臺機(jī)器上，這種情況下只需要將索引進(jìn)行本地拷貝即可。同前面類似，我們定義一個 Transporter 接口。
清單 5. Transporter 接口
public interface Transporter {
public void transport(File file);
} |
以 FTP 方式傳輸為例，我們使用 Commons Net 完成傳輸?shù)牟僮鳌?/p> public void transport(File file) throws TransportException {
FTPClient client = new FTPClient();
client.connect(host);
client.login(username, password);
client.changeWorkingDirectory(remotePath);
transportRecursive(client, file);
client.disconnect();
}
public void transportRecursive(FTPClient client, File file) {
if (file.isFile() && file.canRead()) {
client.storeFile(file.getName(), new FileInputStream(file));
} else if (file.isDirectory()) {
client.makeDirectory(file.getName());
client.changeWorkingDirectory(file.getName());
File[] fileList = file.listFiles();
for (File f : fileList) {
transportRecursive(client, f);
}
}
}
|
對其他傳輸方案也有各自的方案進(jìn)行處理，具體使用哪個 Transporter 的實(shí)現(xiàn)被配置在 Spring 風(fēng)格的索引模塊配置文件中。傳輸?shù)姆绞绞庆`活的。比如當(dāng)需要強(qiáng)調(diào)安全性時，我們可以換用基于 SSL 的 FTP 進(jìn)行傳輸。所需要做的只是開發(fā)一個使用 FTP over SSL 的 Transporter 實(shí)現(xiàn)，并在配置文件中更改 Transporter 的實(shí)現(xiàn)即可。
進(jìn)行搜索 在做了這么多之后，我們開始接觸和用戶關(guān)聯(lián)最為緊密的搜索模塊。注意，我們的框架不包括一個搜索的 Web 前端界面。但是類似這樣的界面可以在搜索模塊的基礎(chǔ)上方便地開發(fā)出來。基于已經(jīng)收集好的索引進(jìn)行搜索是個很簡單的過程。Lucene 已經(jīng)提供了功能強(qiáng)大的 IndexSearcher 及其子類。在這個部分，我們不會再介紹如何使用這些類，而是關(guān)注在前文提到過的資源元數(shù)據(jù)上。元數(shù)據(jù)從各個資源所在的文件夾中讀取得到，它在搜索模塊中扮演重要的角色。 構(gòu)建一個查詢 對 不同資源進(jìn)行搜索的查詢方法并不一樣。例如搜索一個論壇里的所有留言時，我們關(guān)注的一般是留言的標(biāo)題、作者和內(nèi)容；而當(dāng)搜索一個 FTP 站點(diǎn)時，我們更多關(guān)注的是文件名和文件內(nèi)容。另一方面，我們有時可能會使用一個查詢?nèi)ニ阉鞫鄠€資源的結(jié)果。這正是之前我們在前面所提到的元數(shù)據(jù)中 searchableFields 和 resourceName 屬性的作用。前者指出一個資源中哪些字段是參與搜索的；后者則用于在搜索時確定使用哪個或者哪些索引。從技術(shù)細(xì)節(jié)來說，只有有了這些信息，我們才可以構(gòu)造出可用的 Query 對象。 呈現(xiàn)搜索結(jié)果 當(dāng)從 IndexSearcher 對象得到搜索結(jié)果（Hits） 之后，當(dāng)然我們可以直接從中獲取需要的值，再格式化予以輸出。但一來格式化輸出搜索結(jié)果（尤其在 Web 應(yīng)用中）是個很常見的需求，可能會經(jīng)常變更；二來結(jié)果的呈現(xiàn)格式應(yīng)該是由分散的資源各自定義，而不是交由搜索模塊來定義?；谏厦鎯蓚€原因，我們的框架將 使用在資源收集端配置結(jié)果輸出格式的方式。這個格式由資源元數(shù)據(jù)中的 hitTextPattern 屬性定義。該屬性是一個字符串類型的值，支持兩種語法 - 形如
${field_name} 的子字符串都會被動態(tài)替換成查詢結(jié)果中各個 Document 內(nèi) Field 的值。 - 形如
$function(...) 的被解釋為函數(shù)，括號內(nèi)以逗號隔開的符號都被解釋成參數(shù)，函數(shù)可以嵌套。 例如搜索“具體”返回的搜索結(jié)果中包含一個 Document 對象，其 Field 如下表： | Field 名稱 | Field 內(nèi)容 | | url | http://example.org/article/1.html | | title | 示例標(biāo)題 | | content | 這里是具體的內(nèi)容。 | 那么如果 hitTextPatten 被設(shè)置為“<a href="${url}">${title}</a><br/>$highlight(${content}, 5, "<b>", "</b>")”，返回的結(jié)果經(jīng)瀏覽器解釋后可能的顯示結(jié)果如下（這只是個演示鏈接，請不要點(diǎn)擊）： 示例標(biāo)題
這里是具體... 上面提到的 $highlight() 函數(shù)用于在搜索結(jié)果中取得最匹配的一段文本，并高亮顯示搜索時使用的短語，其第一個參數(shù)是高亮顯示的文本，第二個參數(shù)是顯示的文本長度，第三和第四個參數(shù)是高亮文本時使用的前綴和后綴。 可以使用正則表達(dá)式和文本解析來實(shí)現(xiàn)前面所提到的語法。我們也可以使用 JavaCC 定義 hitTextPattern 的文法，進(jìn)而生成詞法分析器和語法解析器。這是更為系統(tǒng)并且相對而言不易出錯的方法。對 JavaCC 的介紹不是本文的重點(diǎn)，您可以在下面的 閱讀資源 中找到學(xué)習(xí)資料。
相關(guān)產(chǎn)品 下面列出的是一些與我們所提出的框架所相關(guān)或者類似的產(chǎn)品，您可以在 學(xué)習(xí)資料 中更多地了解他們。 IBM?OmniFind?Family OmniFind 是 IBM 公司推出的企業(yè)級搜索解決方案。基于 UIMA (Unstructured Information Management Architecture) 技術(shù)，它提供了強(qiáng)大的索引和獲取信息功能，支持巨大數(shù)量、多種類型的文檔資源（無論是結(jié)構(gòu)化還是非結(jié)構(gòu)化），并為 Lotus?Domino?和 WebSphere?Portal 專門進(jìn)行了優(yōu)化。 Apache Solr Solr 是 Apache 的一個企業(yè)級的全文檢索項(xiàng)目，實(shí)現(xiàn)了一個基于 HTTP 的搜索服務(wù)器，支持多種資源和 Web 界面管理，它同樣建立在 Lucene 之上，并對 Lucene 做了很多擴(kuò)展，例如支持動態(tài)字段及唯一鍵，對查詢結(jié)果進(jìn)行動態(tài)分組和過濾等。 Google SiteSearch 使 用 Google 的站點(diǎn)搜索功能可以方便而快捷地建立一個站內(nèi)搜索引擎。但是 Google 的站點(diǎn)搜索基于 Google 的網(wǎng)絡(luò)爬蟲，所以無法訪問受保護(hù)的站點(diǎn)內(nèi)容或者 Intranet 上的資源。另外，Google 所支持的資源類型也是有限的，我們無法對其進(jìn)行擴(kuò)展。 SearchBlox? SearchBlox 是一個商業(yè)的搜索引擎構(gòu)建框架。它本身是一個 J2EE 組件，和我們的框架類似，也支持對網(wǎng)頁和文件系統(tǒng)等資源進(jìn)行索引，進(jìn)而進(jìn)行搜索。
還需考慮的問題 本文介紹的思想試圖利用開源的工具解決中小型應(yīng)用中的常見問題。當(dāng)然，作為一個框架，它還有很多不足， 下面列舉出一些可以進(jìn)行改進(jìn)的地方。 性能考慮 當(dāng) 需要進(jìn)行索引的資源數(shù)目不多時，隔一定的時間進(jìn)行一次完全索引不會占用很長時間。使用一臺 2G 內(nèi)存，Xeon 2.66G 處理器的服務(wù)器進(jìn)行實(shí)際測試，發(fā)現(xiàn)對數(shù)據(jù)庫資源的索引占用的時間很少，一千多條記錄花費(fèi)的時間在 1 秒到 2 秒之內(nèi)。而對 1400 多個文件進(jìn)行索引耗時大約十幾秒。但在大型應(yīng)用中，資源的容量是巨大的，如果每次都進(jìn)行完整的索引，耗費(fèi)的時間會很驚人。我們可以通過跳過已經(jīng)索引的資源 內(nèi)容，刪除已不存在的資源內(nèi)容的索引，并進(jìn)行增量索引來解決這個問題。這可能會涉及文件校驗(yàn)和索引刪除等。 另一方面，框架可以提供查詢緩存來提高查詢效率。框架可以在內(nèi)存中建立一級緩存，并使用如 OSCache 或 EHCache 實(shí)現(xiàn)磁盤上的二級緩存。當(dāng)索引的內(nèi)容變化不頻繁時，使用查詢緩存更會明顯地提高查詢速度、降低資源消耗。 分布式索引 我 們的框架可以將索引分布在多臺機(jī)器上。搜索資源時，查詢被 flood 到各個機(jī)器上從而獲得搜索結(jié)果。這樣可以免去傳輸索引到某一臺中央服務(wù)器的過程。當(dāng)然也可以基于實(shí)現(xiàn)了分布式哈希表 （DHT）的結(jié)構(gòu)化 P2P 網(wǎng)絡(luò)，配合索引復(fù)制 (Replication)，使得應(yīng)用程序更為安全，可靠，有伸縮性。在 閱讀資料 中給出了 一篇關(guān)于構(gòu)建分布式環(huán)境下全文搜索的可行性的論文。 安全性 目前我們的框架并沒有涉及到安全性。除了依賴資源本身的訪問控制（如受保護(hù)的網(wǎng)頁和文件系統(tǒng)等）之外，我們還可以從兩方面增強(qiáng)框架本身的安全性： - 考慮到一個組織的搜索功能對不同用戶的權(quán)限設(shè)置不一定一樣，可以支持對用戶角色的定義，實(shí)行對搜索模塊的訪問控制。
- 在資源索引模塊中實(shí)現(xiàn)一種機(jī)制，讓資源可以限制自己暴露的內(nèi)容，從而縮小索引模塊的索引范圍。這可以類比 robots 文件可以規(guī)定搜索引擎爬蟲的行為。
總結(jié) 通 過上文的介紹，我們認(rèn)識了一個可擴(kuò)展的框架，由索引模塊和搜索模塊兩部分組成。它可以靈活地適應(yīng)不同的應(yīng)用場景。如果需要更獨(dú)特的需求，框架本身預(yù)留了可 以擴(kuò)展的接口，我們可以通過實(shí)現(xiàn)這些接口完成功能的定制。更重要的是這一切都是建立在開源軟件的基礎(chǔ)之上。希望本文能為您揭示開源的力量，體驗(yàn)用開源工具 組裝您自己的解決方案所帶來的莫大快樂。
下載 | 描述 | 名字 | 大小 | 下載方法 | | 一個示例搜索模塊配置文件 | config.zip | 2 KB | HTTP |
參考資料 學(xué)習(xí)
獲得產(chǎn)品和技術(shù)
關(guān)于作者 | | | | 仇寅是南京大學(xué)軟件學(xué)院的本科四年級學(xué)生，目前在 IBM 上海 SAL&FIT 部門實(shí)習(xí)。仇寅熱愛開源活動，并愿意積極參與。他擔(dān)任學(xué)院的教學(xué)支持系統(tǒng)的維護(hù)和開發(fā)人員已經(jīng)有一年多的時間。他感興趣的方向是 Java 技術(shù)和分布式應(yīng)用。 | | 
