Java EE解決方案中的消息傳遞的必要性

考慮一個工作進程，該進程在Web上搜索特定數據。需要另一個過程來索引第一個過程的結果以備後用。索引部分涉及以特定的方式將原始數據（搜索結果）寫入龐大的分佈式HBase存儲庫。我不能判斷這兩個過程的速度相互比較。我們可能會遇到這樣一種情況：其中一種系統暫時關閉，需要在喚醒時立即執行任務。我正在使用JavaEE。目前，這是我想要實現這一點的方式。Java EE解決方案中的消息傳遞的必要性

第一個進程將其搜索結果存儲在MySQL數據庫中，併發送一條消息，其中包含已放入表中的新行的ID。
MOM喚醒第二個進程來使用存儲在MySQL數據庫中的新原始數據。
第二個進程在完成索引真實數據庫（HBase）中的數據時清除MySQL表。

我需要專家對我的設計進行評論以驗證其合適性。例如，如果第二個過程不斷輪詢表格以查看是否有新記錄呢？我是否使用了正確的技術，或者這是一種矯枉過正的行爲？我應該簡化我的設計還是錯過了一些東西？如果我的解決方案合適，在實施過程中是否應該記住一些事項？提前致謝。

來源

2012-10-09 Arash Shahkar

如果可能的話，我會堅持一個更簡單的設計，丟棄MySQL登臺表並堅持到JMS。

所以，這樣的事情會做到這一點：

[P1]將搜索結果中的一些JMS隊列「INDEX.QUEUE」。
[P2]簡單地異步消費隊列「INDEX.QUEUE」的消息，並根據消息有效載荷中的搜索結果生成搜索索引。

消息是有幫助你完成這些任務，輪詢數據庫表幾乎是一樣的，但麻煩，所以當你有一個持久事務MOM是專爲這個任務爲什麼推倒重來。

來源

2012-10-09 18:03:29

謝謝。如果信息量增加會發生什麼？考慮隊列中的數十條消息，每條消息的大小爲10-50 MB。在這種情況下擁有臨時表是否更好，還是沒有什麼區別？ –

當然。大小確實很重要，但對於所有主要供應商而言，<50MB應該沒問題。實際上，JMS實現和數據庫底層的技術並沒有太大的不同，在一些實現中，JMS消息甚至存儲在數據庫表內。您尚未說明運行的是哪個軟件堆棧，但您可能必須調整MOM配置中的限制。通常，隊列中消息的最大總大小僅僅是物理服務器資源的問題。我已經看到單個隊列中的GB數據在等待處理而沒有問題。 –

我正在使用GlassFish v3，它可以輕鬆配置爲使用數據庫進行消息存儲，就像您剛纔所說的那樣。你的建議確實有幫助。 –

Java EE解決方案中的消息傳遞的必要性

回答

相關問題