前言
在過去的工作中，用過rabbitmq和activimq，並看到別人用過kafka和rocketmq。
但是一直侷限於簡單的使用，相關的技術急需進一步提高。
正好最近學習springcloud組件時，有兩部分內容：bus消息總線和stream消息驅動，都涉及了mq。因此決定先暫停springcloud，立即着手mq的進一步學習。
上邊的幾項技術雖然都是mq消息隊列，但是卻有不少的區別，而其中一個繞不開的話題就是他們支持的協議和規範，就我目前所知的來說，java 開發用的較多的可能就是jms規範和amqp協議。
在進行對比學習的過程中，發現網上很多博客對比分析的很清晰，便覺得不需要再重複造輪子，以下是來自轉載的jms和amqp的對比，進行了一些簡單的格式優化。
轉載一
以下內容轉載自：https://blog.csdn.net/hpttlook/article/details/23391967
初次接觸消息隊列時，在網上搜索，總是會提到如JMS、AMQP等一些術語。查看了一些文檔，對JMS和AMQP的一些理解記錄如下。
JMS
通常而言提到JMS（Java MessageService）實際上是指JMS API。JMS是由Sun公司早期提出的消息標準，旨在爲java應用提供統一的消息操作，包括create、send、receive等。JMS已經成爲Java Enterprise Edition的一部分。
從使用角度看，JMS和JDBC擔任差不多的角色，用戶都是根據相應的接口可以和實現了JMS的服務進行通信，進行相關的操作。
JMS通常包含如下一些角色：
Elements
Notes
JMS provider
實現了JMS接口的消息中間件，如ActiveMQ:
- JMS client
生產或者消費消息的應用- JMS producer/publisher
JMS消息生產者- JMS consumer/subscriber
JMS消息消費者- JMS message
消息，在各個JMS client傳輸的對象；- JMS queue
Provider存放等待被消費的消息的地方- JMS topic
一種提供多個訂閱者消費消息的一種機制；在MQ中常常被提到，topic模式。
JMS提供了兩種消息模型，peer-2-peer(點對點)以及publish-subscribe（發佈訂閱）模型。
當採用點對點模型時，消息將發送到一個隊列，該隊列的消息只能被一個消費者消費。
而採用發佈訂閱模型時，消息可以被多個消費者消費。在發佈訂閱模型中，生產者和消費者完全獨立，不需要感知對方的存在。
消息如何從producer端達到consumer端由message-routing來決定。在JMS中，消息路由非常簡單，由producer和consumer鏈接到同一個queue（p2p）或者topic（pub/sub）來實現消息的路由。
JMSconsumer同時支持message selector（消息選擇器），通過消息選擇器，consumer可以只消費那些通過了selector篩選的消息。在JMS兄中，消息路由機制的圖示如下：
常見的消息隊列，大部分都實現了JMS API，可以擔任JMS provider的角色，如ActiveMQ，Redis以及RabbitMQ等。
AMQP
AMQP（advanced message queuing protocol）在2003年時被提出，最早用於解決金融領不同平臺之間的消息傳遞交互問題。
顧名思義，AMQP是一種協議，更準確的說是一種binary wire-level protocol（鏈接協議）。這是其和JMS的本質差別，AMQP不從API層進行限定，而是直接定義網絡交換的數據格式。
這使得實現了AMQP的provider天然性就是跨平臺的。意味着我們可以使用Java的AMQP provider，同時使用一個python的producer加一個rubby的consumer。
從這一點看，AQMP可以用http來進行類比，不關心實現的語言，只要大家都按照相應的數據格式去發送報文請求，不同語言的client均可以和不同語言的server鏈接。
在AMQP中，消息路由（messagerouting）和JMS存在一些差別，在AMQP中增加了Exchange和binding的角色。producer將消息發送給Exchange，binding決定Exchange的消息應該發送到那個queue，而consumer直接從queue中消費消息。queue和exchange的bind有consumer來決定。AMQP的routing scheme圖示過程如下：
目前AMQP逐漸成爲消息隊列的一個標準協議，當前比較流行的rabbitmq、stormmq都使用了AMQP實現。
最後將JMS和AMQP的各項對比如下：
| JMS | AMQP | |
|---|---|---|
| 定義 | Java api | Wire-protocol |
| 跨語言 | 否 | 是 |
| 跨平臺 | 否 | 是 |
| Model | 提供兩種消息模型： （1）、Peer-2-Peer （2）、Pub/sub |
提供了五種消息模型： （1）、direct exchange （2）、fanout exchange （3）、topic change （4）、headers exchange （5）、system exchange 本質來講，後四種和JMS的pub/sub模型沒有太大差別，僅是在路由機制上做了更詳細的劃分； |
| 支持消息類型 | 多種消息類型： TextMessage MapMessage BytesMessage StreamMessage ObjectMessage Message （只有消息頭和屬性） |
byte[] 當實際應用時，有複雜的消息，可以將消息序列化後發送。 |
| 綜合評價 | JMS 定義了JAVA API層面的標準；在java體系中，多個client均可以通過JMS進行交互，不需要應用修改代碼，但是其對跨平臺的支持較差； | AMQP定義了wire-level層的協議標準；天然具有跨平臺、跨語言特性。 |
參考文檔：
轉載二
轉載自：https://blog.csdn.net/u013160104/article/details/19835525
通信平臺的區別
JMS:
只允許基於JAVA實現的消息平臺的之間進行通信
AMQP:
允許多種消息協議進行通信,比如ruby的storm和java的jms都可以在AMQP上進行通信。
結論: AMQP允許多種技術同時進行協議通信
通信機制的區別
JMS:
消息生產者和消息消費者必須知道對方的Queue
AMQP:
消息生產者和消息消費者無須知道對方的Queue,消息生產者將Exchange通過Route key和任意Queue綁定。消息消費者通過Route key從任意Queue中獲取Exchange.
消息傳輸機制的區別
JMS:
JMS支持PTP和publis/subscribe機制,PTP只可以點對點通信,public/subscribe在一端發出請求後所有其他端收到消息
AMQP:
- 所有RouteKey相同的Queue接受到數據
- 所有相同的Exchange的Queue接受到數據
- 所有wilecard的Exchange的Queue接受到數據
- 可以讓webservice等接受到數據