1、是什麼
1.1. Java Message Service
JMS即Java消息服務（Java Message Service）應用程序接口，是一個Java平臺中關於面向消息中間件（MOM）的API，用於在兩個應用程序之間，或分佈式系統中發送消息，進行異步通信。Java消息服務是一個與具體平臺無關的API，絕大多數MOM提供商都對JMS提供支持。
JMS允許應用程序組件基於JavaEE平臺創建、發送、接收和讀取消息。它使分佈式通信耦合度更低，消息服務更加可靠以及異步性。
1.2. 在提到JMS時，我們通常會說到一些術語
解釋如下：
（1）消息中間件（JMS Provider) ： 指提供了對JMS協議的第三方組件，比如ActiveMQ就是一個消息中間件，另外比較知名的還有KFA, Rabbit MQ等。
（2）消息模式：分爲點對點（Point to Point，即P2P）和發佈/訂閱（Pub/Sub)，對應的數據結構分別是隊列（Queue)和主題（Topic)
（3）消息（Message): 通信內容的載體，其結構主要分爲消息頭，屬性和消息體，並且根據存儲結構的不同分爲好幾種，後面會詳細提到。
（4）消息生產者：產生消息的一方，在P2P模式下，指消息發送者(Sender)，在P/S模式下指消息發佈者(Publisher)
（5）消息消費者：接收消息的一方，對應於兩種模式分別是消息接收者（Receiver）和消息訂閱者(Subscriber)
1.3. JMS消息模型(即點對點和發佈訂閱模型)
（1）Point-to-Point(P2P)
（2）Publish/Subscribe(Pub/Sub)
2、 爲什麼用
部分業務，不用實時RPC，而使用消息中間件異步處理。
（1）解耦模塊；
（2）異步調用；
（3）消息持久化；
（4）消息削峯。
3、 怎麼用
3.1. 消息中間件對比
消息中間件區分，轉自：中華石杉Java工程師面試突擊
3.1.1 ActiveMQ
單機吞吐量：萬級
topic數量都吞吐量的影響：
時效性：ms級
可用性：高，基於主從架構實現高可用性
消息可靠性：有較低的概率丟失數據
功能支持：MQ領域的功能極其完備
總結：
非常成熟，功能強大，在早些年業內大量的公司以及項目中都有應用。
偶爾會有較低概率丟失消息。
現在社區以及國內應用都越來越少，官方社區現在對ActiveMQ 5.x維護越來越少，幾個月才發佈一個版本。
主要是基於解耦和異步來用的，較少在大規模吞吐的場景中使用。
3.1.2. RabbitMQ
單機吞吐量：萬級
topic數量都吞吐量的影響：
時效性：微秒級，延時低是一大特點。
可用性：高，基於主從架構實現高可用性。
消息可靠性：
功能支持：基於erlang開發，所以併發能力很強，性能極其好，延時很低。
總結：
erlang語言開發，性能極其好，延時很低；
吞吐量到萬級，MQ功能比較完備 。
開源提供的管理界面非常棒，用起來很好用。
社區相對比較活躍，幾乎每個月都發布幾個版本分。
在國內一些互聯網公司近幾年用rabbitmq也比較多一些 但是問題也是顯而易見的，RabbitMQ確實吞吐量會低一些，這是因爲他做的實現機制比較重。
erlang開發，很難去看懂源碼，基本職能依賴於開源社區的快速維護和修復bug。
rabbitmq集羣動態擴展會很麻煩，不過這個我覺得還好。其實主要是erlang語言本身帶來的問題。很難讀源碼，很難定製和掌控。
3.1.3. RocketMQ
單機吞吐量：十萬級
topic數量都吞吐量的影響：topic可以達到幾百，幾千個的級別，吞吐量會有較小幅度的下降。可支持大量topic是一大優勢。
時效性：ms級。
可用性：非常高，分佈式架構。
消息可靠性：經過參數優化配置，消息可以做到0丟失。
功能支持：MQ功能較爲完善，還是分佈式的，擴展性好。
總結：
接口簡單易用，可以做到大規模吞吐，性能也非常好，分佈式擴展也很方便，社區維護還可以，可靠性和可用性都是ok的，還可以支撐大規模的topic數量，支持複雜MQ業務場景。
而且一個很大的優勢在於，源碼是java，我們可以自己閱讀源碼，定製自己公司的MQ，可以掌控。
社區活躍度相對較爲一般，不過也還可以，文檔相對來說簡單一些，然後接口這塊不是按照標準JMS規範走的有些系統要遷移需要修改大量代碼。
3.1.4. Kafka
單機吞吐量：十萬級，最大的優點，就是吞吐量高。
topic數量都吞吐量的影響：topic從幾十個到幾百個的時候，吞吐量會大幅度下降。所以在同等機器下，kafka儘量保證topic數量不要過多。如果要支撐大規模topic，需要增加更多的機器資源。
時效性：ms級。
可用性：非常高，kafka是分佈式的，一個數據多個副本，少數機器宕機，不會丟失數據，不會導致不可用。
消息可靠性：經過參數優化配置，消息可以做到0丟失。
功能支持：功能較爲簡單，主要支持簡單的MQ功能，在大數據領域的實時計算以及日誌採集被大規模使用。
總結：
kafka的特點其實很明顯，就是僅僅提供較少的核心功能，但是提供超高的吞吐量，ms級的延遲，極高的可用性以及可靠性，而且分佈式可以任意擴展。
同時kafka最好是支撐較少的topic數量即可，保證其超高吞吐量。
kafka唯一的一點劣勢是有可能消息重複消費，那麼對數據準確性會造成極其輕微的影響，在大數據領域中以及日誌採集中，這點輕微影響可以忽略。
3.1.5. 最後
（1）一般的業務系統要引入MQ，最早大家都用ActiveMQ，但是現在確實大家用的不多了，沒經過大規模吞吐量場景的驗證，社區也不是很活躍。ActiveMQ缺點：根據其他用戶反饋，會出莫名其妙的問題，切會丟失消息。其重心放到activemq6.0產品—apollo上去了，目前社區不活躍，且對 5.x 維護較少；Activemq 不適合用於上千個隊列的應用場景。
（2）後來大家開始用RabbitMQ，但是確實erlang語言阻止了大量的java工程師去深入研究和掌控他，對公司而言，幾乎處於不可控的狀態，但是確實人家是開源的，比較穩定的支持，活躍度也高。RabbitMQ缺點：erlang語言難度較大。集羣不支持動態擴展。
（3）而用RocketMQ，現在確實越來越多的公司使用，確實很不錯，但是要想好社區萬一突然黃掉的風險。Apache頂級項目。RocketMQ缺點：產品較新，文檔比較缺乏。沒有在 mq核心中去實現JMS 等接口，對已有系統而言不能兼容。阿里內部還有一套未開源的 MQ API，這一層 API可以將上層應用和下層 MQ 的實現解耦（阿里內部有多個 mq的實現，如 notify、作者 何鵬 關注分佈式存儲與計算相關框架，包括 Hadoop、 YARN、 HBase、 Storm、 Spark、 MQ 等 [email protected]，metaq2.x，rocketmq 等），使得下面 mq 可以很方便的進行切換和升級而對應用無任何影響，目前這一套東西未開源。
（4）如果是大數據領域的實時計算、日誌採集等場景，用Kafka是業內標準的，絕對沒問題，社區活躍度很高，絕對不會黃，何況幾乎是全世界這個領域的事實性規範。
所以中小型公司，技術實力較爲一般，技術挑戰不是特別高，用RabbitMQ是不錯的選擇；大型公司，基礎架構研發實力較強，用RocketMQ是很好的選擇。
Rocketmq 的前身爲 metaq， metaq 的第一個版本是可以看成是 linkedin 的 kafka（scala）的 java 版本，並對其增加了事務的支持。 rocketmq 爲 metaq3.0， 相比於原始 kafka，其擅長點出了原始的 log collecting 之外，還增加諸如HA、 事務等特性，使得從功能點上講， 可以替代傳統大部分 MQ。
目前已經在阿里開始大規模應用，並且預計未來會逐漸在阿里取代 notify， meta 2.x 以前的所有隊列。 由於rocketmq 還比較新，且官方沒有給出相應的 benchmark。 而 rocketmq 社區主要活躍者均是中國國內人員，因此不便於直接對比 rocketmq 和其他隊列。在這裏用 kafka 和其他隊列進行對比， rocketmq 的性能比 kafka 還要好一些。
Kafka需要依賴Zookeeper。Rocketmq不需要，自身實現了Nameserver。
在Kafka裏面，Maser/Slave是選舉出來的！！！RocketMQ不需要選舉！！！
在Kafka裏面，Maser/Slave是選舉出來的！！！RocketMQ不需要選舉！！！
在Kafka裏面，Maser/Slave是選舉出來的！！！RocketMQ不需要選舉！！！
重要的話說三遍。具體來說，在Kafka裏面，Master/Slave的選舉，有2步：第1步，先通過ZK在所有機器中，選舉出一個KafkaController；第2步，再由這個Controller，決定每個partition的Master是誰，Slave是誰。
這裏的Master/Slave是動態的，也就是說：當Master掛了之後，會有1個Slave切換成Master。
而在RocketMQ中，不需要選舉，Master/Slave的角色也是固定的。當一個Master掛了之後，你可以寫到其他Master上，但不會說一個Slave切換成Master。
這種簡化，使得RocketMQ可以不依賴ZK就很好的管理Topic/queue和物理機器的映射關係了，也實現了高可用。