全文檢索、資料採擷、推薦引擎系列2---非同步服務實現

正向前一篇分析的，在全文檢索、資料採擷、推薦引擎的後臺系統中，通常可以提供三種類型的服務：同步服務、非同步服務、後臺服務。對於同步服務可以採用Web Service、XML Over HTTP或Restful服務，我在專案中就採用了Jason over HTTP，主要考慮Javascript解析Json效率較高，但是還要看各人喜好。對於非同步服務在實現上，如果選用Java做為程式設計語言，基本就需要選擇JMS了。而後臺服務主要是定時任務，可以採用新版JEE中的Timer服務，或直接使用Timer。

在JMS實現非同步服務中，最簡單的方法是採用消息驅動Bean來實現，但是JMS中有兩種機制：一種是Queue，另一種是Topic，那麼選哪種好呢？通常在需要松藕合系統中，由於業務邏輯非常複雜，需求集成多個系統及功能，而且系統及功能可能在運行時加入等原因，一般採用消息匯流排機制，如OpenESB。這種特性也是我的系統中所需要，但是引入重量級的ESB技術又是我所不願意的，因此我選擇了JMS Topic模式來實現消息驅動Bean。這樣即使當系統上線後，要加入新功能，例如新使用者註冊時，需要將使用者信用卡資訊加入緩存中（原來只是將登錄名密碼加入到了緩存中），這時就可以動態部署一個新的消息驅動Bean，這樣系統可以不進行任何修改加入新功能，實現類似消息匯流排機制。

為此，我在系統中建立了消息驅動Bean-MainMdb，用於監聽jms/MainTopic這個Topic。

例如，當使用者發佈一條博客資訊時，Web前端系統首先將該博客的資訊存入資料庫，然後會向jms/MainTopic發送一條消息，消息類別為博客添加，參數為博客編號。後臺的消息驅動Bean收到該消息，在onMessage方法中，通過博客編號，找到博客的詳細資訊，然後將標題、標籤、關鍵字、摘要、正文等文本資訊建立全文檢索索引，然後會計算文章分詞後每個詞在本篇博客中的出現頻率以及與本博客的相關度（即TF/iDF，計算方法在本系列後續文章中會介紹到），建立術語向量空間，運行自動聚類演算法，找出基於內容的相似博客，同時根據需要，可能還需要和使用者進行自動聚類分析，找到可能喜歡這篇博客的用戶。通常由於建立全文索引和進行基於內容的推薦引擎計算需要較長時間，如果採用同步服務，那麼使用者等待時間會比較長，用戶體驗不好，但是如果採用非同步服務方式實現，可以立即向使用者顯示成功資訊，耗時工作採用非同步方式來完成。但是用戶如果再進行下一步操作時，如進行全文檢索，查看其他博客或其他用戶等，由於已經過去了對系統來說足夠長的時間，全文索引和基於內容的推薦運算已經完成，因此可以呈獻出准即時的效果。