瞭解什麼時候使用RabbitMQ

人們如何作出決定？在平常生活中，情緒每每是第一動力。但當人們須要承擔長期後果時，不可能純靠衝動行事。聰明者只會在內心有數後纔會靠直覺作出決定。

現在市場上有數十種發送消息的技術，無數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的最佳場景，例如：

1. 您的應用程序須要使用現有協議的任意組合，如AMQP 0-9-1，STOMP，MQTT，AMQP 1.0。

2. 您須要基於每一個消息（死信隊列等）進行更精細的一致性控制/保證。可是，Kafka最近添加了更優的支持。

3. 您的應用程序須要點對點，請求/回覆、發佈/訂閱，具備消息傳遞的多樣性

4. 至消費者複雜的路由，使用強大的路由邏輯集成多個服務/應用程序

5. 在其餘軟件的幫助下，RabbitMQ還能夠有效地解決上面幾個Kafka強大的用例。當應用程序須要訪問流歷史時，RabbitMQ一般與Apache Cassandra一塊兒使用，對於須要「無限」隊列的應用程序，RabbitMQ一般與LevelDB插件一塊兒使用，但這兩種功能都不附帶RabbitMQ自己。

 

開發經驗

RabbitMQ正式支持Java，Spring，.NET，PHP，Python，Ruby，JavaScript，Go，Elixir，Objective-C，Swift - 經過社區插件與許多其餘客戶端的devtools一塊兒支持。RabbitMQ客戶端庫已經成熟而且文檔齊全。