使用JMS隊列的潛在缺陷？

Question

我被要求設計和實現一個系統，用於從大量設備接收大量自動化傳感器數據。這些數據將定期生成並作爲xml發送到服務器上。如果設備沒有收到來自服務器的特定確認，設備將繼續重新發送相同的數據。在將數據插入主數據庫中的多個表格之前，需要對這些數據進行一些潛在的繁重處理，另外還需要將一些數據點排入其他外部URL。

我正計劃使用一個Java應用程序服務器（傾向於GlassFish）和一個servlet來接收傳入數據。我想實現某種排隊機制來臨時存儲數據，以便返回到傳感器的響應不依賴於所有中間處理。分離的獨立隊列也是數據重定向片的要求。之後做一些研究的兩個主要的選擇似乎是：

1）應用服務器上安裝一個數據庫，並使用表格各種隊列。隊列將由Java應用程序處理，或者在應用程序服務器中運行，或者作爲自己的服務單獨運行。

2）使用數據庫支持的JMS解決方案來實現排隊。

我對JMS並不熟悉，但從我讀過的內容來看，它似乎是這種情況下更好的解決方案。主要要求是傳感器數據在處理之前不會丟失或丟失，並且或多或少地按順序處理。我們還希望在特定時間停止某些隊列的處理，但仍讓他們累積數據並使這些消息永不過期。

隨着戰略1，我很明顯如何滿足這些要求，但它可能不如健壯性和可擴展性，並且比戰略2更復雜，因爲我需要編寫自己的多線程代碼來處理各種獨立隊列。我想知道爲什麼使用JMS隊列可能存在的潛在缺陷，因爲我從來沒有和他們合作過。

，數據安全是一個大問題，所以我需要確保JMS可以保證在重新啓動服務器，停電的情況下，無數據丟失，或者如果隊列中獲得某種原因非常大。例如，在一段時間內完成主數據庫事務的問題可能會導致JVM耗盡內存，崩潰並丟失所有累積的數據？ （這將是噩夢場景）。

此外，我想知道是否有任何方法可以通過應用服務器管理工​​具暫停JMS隊列處理，或者輕鬆看到隊列中有什麼（我將排隊一個對象，這將是消息xml加上一些其他數據，包括收到的時間戳等）。我已經閱讀了幾篇關於相關問題的文章，但希望得到一些直接的反饋。基本上我想知道JMS不是合適的排隊解決方案的實例（如果有的話），以及這是否是其中一種情況。任何意見是極大的讚賞。

Answer 1

卡萊布的有關JMS的好處，答案說得很雄辯，但因爲你是問的陷阱，這是我能想到的。

• 並非所有的JMS實現是相等的。從理論上講，你可以使用任何符合你需要的實現，但除非你準備好進行一些嚴重的負載測試和失敗條件測試，否則根據你的特定用例，你不會知道某個特定的實現不會失敗。
• 大多數JMS使用像關係數據庫這樣的事務性數據存儲作爲它們的後端。這意味着，您不必直接寫入您熟悉的任何數據存儲區，而必須依賴JMS實現在您和存儲的消息之間的額外層。
• 雖然交換JMS實現找到一個完全符合你的需求似乎是因爲同質JMS API的一個簡單的努力，故障處理，JMS服務器監控，以及所有其他很酷的東西重要的功能，上面存在，如果你確實改變了你的實現，那麼除了消息傳遞將會是一件麻煩事。

這就是說，我認爲你會瘋狂地寫自己的DB而不是使用JMS。第一點，ActiveMQ是在許多企業環境中使用的可敬的JMS服務器。關於第二點，事實是，你最終會自己寫這個額外的層來實現消息傳遞，而且你的代碼不會有成千上萬的眼睛的好處（或者是一組單純的工作的付費開發者對客戶做出迴應並確保JMS的實施是可靠的）。關於第三點，以及後端數據存儲的結果也是如此。使用JMS，您將長期保存自己的麻煩。

Answer 2

如果你想要去的JMS路線，獨立JMS兼容的消息代理（從您的應用程序服務器分開）將是一個不錯的選擇。消息代理的範圍從免費開源（如ActiveMQ在http://activemq.apache.org/或OpenMQ在https://mq.dev.java.net/）到大型商業解決方案（IBM的WebSphere MQ在http://www-01.ibm.com/software/integration/wmq/是最大的之一）。

消息中間商報價保證交付（提供服務器並聆聽），你可以做相當多的位，以確保系統故障安全包括集成的備份代理服務器和即時備用電源。如果您的應用程序服務器沒有收到消息，代理隊列最終可能會耗盡空間，但是您可以分配巨大的隊列深度（100 GB），並在消息未得到處理並且隊列到達時讓服務器發送警報一定比例。

你的Java應用程序將隨後在不同的服務器上完全運行，並會以最快的速度連接到代理和拉斷的消息隊列的越好。如果應用程序服務器因任何其他原因崩潰或停止拾取消息，那麼代理將只保留該隊列中的所有消息，直到應用程序服務器再次開始拾取消息爲止。