為什麼要選擇RabbitMQ？而不是ActvieMQ，優勢在哪裡？直接上圖來介紹：

direct

direct型別的Exchange路由規則也很簡單，它會把訊息路由到那些binding key與routing key完全匹配的Queue中。 

以上圖的配置為例，我們以routingKey=”error”傳送訊息到Exchange，則訊息會路由到Queue1（amqp.gen-S9b…，這是由RabbitMQ自動生成的Queue名稱）和Queue2（amqp.gen-Agl…）；如果我們以routingKey=”info”或routingKey=”warning”來發送訊息，則訊息只會路由到Queue2。如果我們以其他routingKey傳送訊息，則訊息不會路由到這兩個Queue中。

RPC

MQ本身是基於非同步的訊息處理，前面的示例中所有的生產者（P）將訊息傳送到RabbitMQ後不會知道消費者（C）處理成功或者失敗（甚至連有沒有消費者來處理這條訊息都不知道）。 但實際的應用場景中，我們很可能需要一些同步處理，需要同步等待服務端將我的訊息處理完成後再進行下一步處理。這相當於RPC（Remote Procedure Call，遠端過程呼叫）。在RabbitMQ中也支援RPC。 

  RabbitMQ  中實現RPC 的機制是：

• 客戶端傳送請求（訊息）時，在訊息的屬性（MessageProperties ，在AMQP
   協議中定義了14中properties ，這些屬性會隨著訊息一起傳送）中設定兩個值replyTo （一個Queue 名稱，用於告訴伺服器處理完成後將通知我的訊息傳送到這個Queue 中）和correlationId （此次請求的標識號，伺服器處理完成後需要將此屬性返還，客戶端將根據這個id瞭解哪條請求被成功執行了或執行失敗）
• 伺服器端收到訊息並處理
• 伺服器端處理完訊息後，將生成一條應答訊息到replyTo 指定的Queue ，同時帶上correlationId 屬性
• 客戶端之前已訂閱replyTo
   指定的Queue ，從中收到伺服器的應答訊息後，根據其中的correlationId屬性分析哪條請求被執行了，根據執行結果進行後續業務處理

總結

本文介紹了RabbitMQ 中個人認為最重要的概念，充分利用RabbitMQ 提供的這些功能就可以處理我們絕大部分的非同步業務了。

RabbitMQ 選型和對比

1.從社群活躍度

按照目前網路上的資料，RabbitMQ 、activeM 、ZeroMQ 三者中，綜合來看，RabbitMQ 是首選。 

2.持久化訊息比較

ZeroMq 不支援，ActiveMq 和RabbitMq 都支援。持久化訊息主要是指我們機器在不可抗力因素等情況下掛掉了，訊息不會丟失的機制。

3.綜合技術實現

可靠性、靈活的路由、叢集、事務、高可用的佇列、訊息排序、問題追蹤、視覺化管理工具、外掛系統等等。

RabbitMq / Kafka 最好，ActiveMq 次之，ZeroMq 最差。當然ZeroMq 也可以做到，不過自己必須手動寫程式碼實現，程式碼量不小。尤其是可靠性中的：永續性、投遞確認、釋出者證實和高可用性。

4.高併發

毋庸置疑，RabbitMQ 最高，原因是它的實現語言是天生具備高併發高可用的erlang 語言。

5.比較關注的比較， RabbitMQ 和 Kafka

RabbitMq 比Kafka 成熟，在可用性上，穩定性上，可靠性上，  RabbitMq  勝於  Kafka  （理論上）。

另外，Kafka 的定位主要在日誌等方面， 因為Kafka 設計的初衷就是處理日誌的，可以看做是一個日誌（訊息）系統一個重要元件，針對性很強，所以 如果業務方面還是建議選擇 RabbitMq 。

還有就是，Kafka 的效能（吞吐量、TPS ）比RabbitMq 要高出來很多。

選型最後總結：

如果我們系統中已經有選擇  Kafka  ，或者   RabbitMq  ，並且完全可以滿足現在的業務，建議就不用重複去增加和造輪子。

可以在  Kafka  和   RabbitMq  中選擇一個適合自己團隊和業務的，這個才是最重要的。但是毋庸置疑現階段，綜合考慮沒有第三選擇。

上面廢話比較多，都是copy過來的，簡單的介紹一下幾個特徵：高可用、PRC、高併發、支援半腦裂問題。最主要的是它是spring boot 和spring cloud首選，官方推薦，3分鐘快速整合才是重點。廢話不多說，直接上配置：

1.application:

2.生產傳送者（一對多）

3.消費者

4.topic 主題傳送