我有一個服務器應用程序A，它在請求到達時產生記錄。我希望這些記錄被保存在數據庫中。但是，我不想讓應用程序A線程通過直接與數據庫通信來花費時間來保存記錄。因此，我想過使用一個簡單的生產者 - 消費者體系結構，其中應用程序A線程生成記錄，另一個應用程序B線程是將記錄保存到數據庫的消費者。在兩個進程之間共享數據的本地消息隊列
我在尋找「最佳」的方式來共享應用程序A和B.一個重要的要求之間的這些記錄是該應用程序的線程將總是能夠發送記錄到IPC系統（例如隊列但可能是一些其他解決方案）。因此，我認爲記錄必須始終存儲在本地，以便應用程序A線程在發生網絡故障時能夠發送記錄事件。
是來到我的心是使用本地消息隊列（如ActiveMQ的）最初的想法。你認爲本地消息隊列是否合適？如果是的話，你推薦一個特定的消息隊列實現嗎？請注意這兩個應用程序都是用Java編寫的。
謝謝，邁克爾
對於這種類型的需求，排隊的解決方案似乎是最適合作爲事件的生產者和消費者能夠孤立地起作用。那裏有很多解決方案，並且我親自與RabbitMQ和ActiveMQ合作。兩者同樣好。我不想在這裏比較它們的性能特徵，但是RabbitMQ是用Erlang編寫的，這是一種用於構建實時應用程序的語言編寫器。
既然你已經在Java平臺上的ActiveMQ可能是一個更好的選擇，並能產生高吞吐量。有了這樣的解決方案，消費者不必一直在線。根據您的事件數據的重要性，您可能還希望擁有持久性隊列和消息，以便在消息代理失敗的情況下，您仍然可以恢復應用程序A生成的重要「事件」消息。
如果有許多應用程序正在生成事件，並且以後如果您希望scale out（或橫向擴展）代理服務，因爲它正在成爲瓶頸，上述兩個解決方案均提供集羣服務。
最後但並非最不重要的，如果你想分享不同的平臺之間的這些事件，你不妨在AMQP格式，它是一個獨立於平臺的線級協議共享異構系統之間的信息共享郵件，我不知道這是否是您的要求。 RabbitMQ和ActiveMQ都支持AMQP。這兩種解決方案都支持MQTT這是一種輕量級消息協議，但您似乎不希望使用MQTT。
還有其他產品，如HornetQ和Apache Qpid這也是生產就緒的解決方案，但我沒有親自使用它們。
我覺得排隊的解決方案是在可維護性，參與的應用和性能的鬆耦合本質而言一個最好的辦法。