RabbitMQ高速瞬態消息傳遞性能

Question

我們正在構建的系統通過外部饋送接收數據。我們的工作是將這些數據分配給多個服務，運行計算並將結果轉發到其他地方 - 典型的發佈者 - 訂閱者情況。我們需要的是非常低延遲的消息。我們不需要堅持像MSMQ這樣的消息。

RabbitMq是否足夠快以實現軟實時消息傳遞？有沒有基準？ 使用它代替TIBCO Rendezvous是個好主意嗎？ 是否還有其他開源軟實時消息選擇？

謝謝。

Answer 1

（我是RabbitMQ的開發者。）

兔子，輕載時，一般有100-400毫秒數量級的延遲，這取決於事情像你的網卡和CPU速度。一旦負載變得稍重，內部緩衝開始出現，並且延遲會稍微增加。您可以放心地預期1ms的延遲，直到帶寬使用（每秒消息數，每秒字節數）開始變高。自然，一旦引入持久性，延遲時間也會增加。

關於基準測試，這裏最大的問題之一是定義對您的應用程序重要的東西。 Java客戶端中包含一些非常簡單的點對點和發佈 - 子時延和吞吐量測量示例;如果您遇到問題，請在rabbitmq-討論清單上詢問！它們與真實世界的應用程序沒有多大關聯，但可能有助於減輕您對延遲或吞吐量微觀基準的擔憂。

最後，現在有許多很好的開源消息傳遞和消息傳遞相關係統。在AMQP的世界裏，除了RabbitMQ，還有Qpid和OpenAMQ。如果你能夠限制你自己的Java（很多人都可以使用ActiveMQ），那麼也有很好的開源JMS服務器。對於Ruby和Python系統來說，許多輕量級系統也在涌現;這些系統傾向於專注於單獨排隊，並且往往不具有AMQP提供的靈活路由功能。

Answer 2

您應該能夠在每個CPU上實現每秒數萬條消息。例如，我們的一個標準測試將每秒25k條消息從Java客戶端推送到在四核COTS debian盒上運行的服務器，並返回給客戶端。客戶端和服務器在同一個機器上運行，因此服務器每秒處理50k條消息，並在客戶端上每秒處理50k條消息。通過在具有更多核心的專用盒子上運行服務器，可以獲得更高的費率。對於基於每秒字節數的速率，請在rabbitmq-discuss郵件列表上詢問。

亞歷克西斯

Answer 3

最好的解決辦法我能想到的你的系統是ZeroMQ。

它沒有堅持，你說你不需要，它非常快速和簡單的使用。

這不是一個AMQP執行（看來你並不需要太多），但它說this guide：

ØMQ（ZeroMQ，0MQ，ZMQ）看起來像一個嵌入式的網絡庫，但就像一個併發框架。它爲您提供套接字，可以傳輸跨越各種傳輸（如進程內，進程間，TCP和多播）的全部消息。您可以使用扇出，發佈 - 訂閱，任務分發和請求回覆等模式將套接字N連接到N。它足夠快成爲集羣產品的結構。它的異步I/O模型爲您提供可擴展的多核應用程序，構建爲異步消息處理任務。它擁有多種語言API，可在大多數操作系統上運行。