我瀏覽了一個開源的通訊軟件和之後的研究提供一些好一點，我碰到這三種產品。我已經拿出了這些初步測試的驅動器，讓他們處理隊列和主題的消息，並且從我讀過的所有這三個產品都可以很好地爲大多數公司提供開源消息傳遞解決方案。我想知道的是，這些產品相對於另一個產品而言有什麼優勢？我特別感興趣的是消息吞吐量，包括持久消息吞吐量，安全性，可擴展性，可靠性，支持，路由功能，管理選項（如度量和監控），以及每個程序在大型商業環境中的運行情況。優勢VS Qpid
首先，我在這方面的專家，但也許我可以給你一些想法的提示。
的ActiveMQ和Qpid都是在Apache傘下，並且是消息隊列。但Qpid是AMQP規範的一個實現。
AMQP是一個協議規範，在電線上水平，使消息可以與其它AMQP消息隊列（例如RabbitMQ的）進行交換。
的ActiveMQ和HornetQ的是隊列，你可以用JMS API使用。 Java消息服務是API級別的規範。
但是你必須通過一個JMS API來訪問Qpid的選項，太。 我認爲表現是次要的思想。擁有一個活躍的社區更重要。
'消息傳遞'涵蓋了很多選擇 - 至少必須有十幾種不同類型的技術可能是正確的答案 - 已經構建了許多生產消息環境，使用各種技術/方法，擁有更好的瞭解你的要求會有所幫助。
您是否需要基於主題的訂閱？你需要多播傳送嗎？你需要動態的用戶/聽衆嗎？即使在找到可接受的發佈者/訂閱源之後，您的聽衆是否還會尋求最佳來源？
您需要擔保交貨嗎？發貨確認？您的發佈商是否存儲任何未傳送的郵件，或者您是否需要郵件系統爲您自動執行此操作？您的Feed數據多久出現一次陳舊 - 例如email-ish警報可以存儲並轉發，但實時定價數據僅適用於很短的時間間隔（然後可能需要消失而不會造成混淆）
您的網絡拓撲結構有多易變？您的訂戶（或發佈商）是否期望住在固定的地址？或者他們是移動設備？他們能否看到更復雜的互聯網絡拓撲需要註冊並可能施加路由限制？如果有的話，任何想法這些拓撲變化的頻率？
你只需要一個java界面嗎？是否有任何用戶可以集成到Windows組件中（比如饋送到Excel中）？
如果您只對比較您指定的同類產品感興趣，那麼您可能已經考慮過這些主題。
對於產品，根據我的經驗，Tibco仍然是吞吐量和可擴展性的領導者，尤其是在實時環境中。下一步將是ibm MQ，特別是在存儲轉發體系結構中。與這兩種產品相比，您可以獲得一定程度的支持，您可以根據這些支持對商業系統的基本部分進行投注。這兩者都有幾十年的歷史。
另一個經常被忽視的選項是Tuxedo的 - 它不是僅提供消息，但剩下的無與倫比的經過驗證的交易能力。 Oracle繼續致力於此產品，同樣，可用的支持水平是首屈一指的。
我喜歡開源解決方案，並且總是很高興能夠免費找到生產質量軟件 - 但如果您正在創建業務基礎架構的基礎部分，那麼活躍的社區可能仍不會表明某個特定的自願項目是否是最佳選擇。
我2c的價值。希望能幫助到你。
我不認爲IBMMQ的速度如你所說。我無法提供太多數據，但據我所知，IBMMQ並不知道速度快。 –
同意 - 你會不會選擇MQ，如果速度是你的主要關注 - 當Tibco公司停止銷售ETX它留給保證快速+的開口。如果對你來說很快就意味着即使是最大的網絡也只有幾毫秒，那麼afaik Tibco RV仍然是最好的選擇。 – chaosless
HornetQ的本地協議速度更快。我可以向你保證。在消息系統 速度不是在一個生產者/消費者測量。您需要擴大規模才能生成有效的報告。 –
基準測試包括了一些業績數字由你來決定，既持久的和短暫的結果。
從他們的網站：
的目標是創建隊列的質量清單，文章，博客文章，幻燈片和視頻對他們的集合。閱讀鏈接文章後，您應該清楚：每個隊列的優缺點，對隊列工作原理的基本瞭解以及每個隊列嘗試實現的內容。基本上，您應該擁有所有需要的信息來決定哪個隊列最適合您的需求。
您可以使用HornetQ的與HornetQ的核心API。 HornetQ是多協議，在不久的將來它可能會AMQP。 –