人們如何做出決定？在日常生活中，情緒往往是第一動力。但當人們需要承擔長期後果時，不可能純靠衝動行事。聰明者只會在心裡有數後才會靠直覺做出決定。
如今市場上有數十種傳送訊息的技術，無數ESB和近100家iPaaS供應商。當然，如何挑選就成為了一個問題。需要批發一堆技術嗎？還是對症下藥？那麼，正確的工具應該是什麼？
這篇文章正是想給那些“無頭蒼蠅”們一些簡單直接的建議，就從如今最時尚最受歡迎的RabbitMQ開始吧！兩者都有自己的起源故事，設計意圖，閃光點，整合功能和開發人員的切身體驗。起源揭示了本軟體的整體設計意圖o。重要的是，本文中的目的是比較兩者圍繞訊息中介的重疊用例，而不是Kafka擅長的“事件儲存/事件源”用例。
起源
RabbitMQ是一個“傳統”訊息中介，可以實現各種訊息傳遞協議。它是首批實現大量功能，客戶端庫，開發工具和質量文件的開源訊息中介之一。RabbitMQ最初是為實現開放式線路協議AMQP而開發的。雖然Java具有像JMS這樣的訊息傳遞標準，但它對於需要分散式訊息傳遞的非Java應用程式沒有幫助，因為它嚴重限制了整合場景，微服務。隨著AMQP的出現，跨語言的靈活性成為開源訊息中介的真實存在。
建築與設計
RabbitMQ作為通用的訊息中介，採用點對點的方式，請求/回覆各類通訊樣式。它使用智慧中介/ “沉默的消費者”模型，專注於向消費者提供一致的訊息傳遞，消費者的消費速度與中介跟蹤消費者狀態的速度大致相似。RabbitMQ是成熟的，在得到正確配置時表現良好，得到很多支援（客戶端庫Java，.NET，node.js，Ruby，PHP和更多語言），並且有許多可用的外掛可以將它擴充套件到更多的用例和整合場景。
RabbitMQ中的通訊可以根據需要同步或非同步。釋出者向中間站傳送訊息，消費者從佇列中檢索訊息。通過交換將生產者與佇列分離，可確保生產者不會受到硬編碼決策的影響。RabbitMQ還提供了許多分散式部署方案（並且確切要求所有節點都能夠解析主機名）。可以將多節點群集設定為群集聯合，並且不依賴於外部服務（但某些群集形成外掛可以使用AWS API，DNS，Consul等）。
要求和用例
RabbitMQ是一種通用的訊息傳遞解決方案，通常用於允許Web伺服器快速響應請求，而不是在使用者等待結果時強制執行複雜的過程。它還可以將訊息分發給多個接收者以供消費，或者在高負載（20k + / sec）下平衡負載。當您的需求超出吞吐量時，RabbitMQ可提供許多功能：可靠的交付，路由，聯合，HA，安全性，管理工具和其他功能。讓我們來看看RabbitMQ的最佳場景，例如：
-
您的應用程式需要使用現有協議的任意組合，如AMQP 0-9-1，STOMP，MQTT，AMQP 1.0。
-
您需要基於每個訊息（死信佇列等）進行更精細的一致性控制/保證。但是，Kafka最近新增了更優的支援。
-
您的應用程式需要點對點，請求/回覆、釋出/訂閱，具有訊息傳遞的多樣性
-
至消費者複雜的路由，使用強大的路由邏輯整合多個服務/應用程式
-
在其他軟體的幫助下，RabbitMQ還可以有效地解決上面幾個Kafka強大的用例。當應用程式需要訪問流歷史時，RabbitMQ通常與Apache Cassandra一起使用，對於需要“無限”佇列的應用程式，RabbitMQ通常與LevelDB外掛一起使用，但這兩種功能都不附帶RabbitMQ本身。
開發經驗
RabbitMQ正式支援Java，Spring，.NET，PHP，Python，Ruby，JavaScript，Go，Elixir，Objective-C，Swift - 通過社群外掛與許多其他客戶端的devtools一起支援。RabbitMQ客戶端庫已經成熟並且文件齊全。