[[337979]]

本文轉載自微信公眾號「Java極客技術」，作者鴨血粉絲 。轉載本文請聯系Java極客技術公眾號。

關于消息隊列，斷斷續續的看了很多資料，一直想抽個時間把這些知識整理記錄下來，但是沒騰出時間來寫，正好所在的項目在實際業務中使用到了消息隊列，索性就將這方面的知識整理一下，可能有理解不到位的地方，望網友批評指出!

一、消息隊列由來

可能在你沒了解消息隊列之前，已經聽過很多概念了，例如 JMS，AMQP，ActiveMQ，RabbitMQ，RocketMQ，Kafka 等等。

一個消息中間件，咋搞出這么多概念?

別慌，我們先從歷史角度來理清這些 MQ 和協議之間的關系!

消息中間件其實誕生的很早，在互聯網應用還是一片荒蕪的年代，有個在美國的印度小哥 Vivek Ranadive 就設想了一種通用軟件總線，采用發布訂閱的模式，類似于電腦主板上的總線，新的設備或者程序如果想和電腦上其他的設備軟件通信，只需要按照協議對接總線就可以完成接入和通信!

在 1983 年，26歲的印度小哥 Vivek Ranadive 創辦了一家公司 Teknekron，實現了世界上第一個消息中間件The Information Bus(TIB)。

很快 TIB 軟件受到了企業的歡迎，最初被高盛集團用于解決金融交易，Teknekron 的業務發展速度甚至引起了當時最牛逼的 IT 公司 IBM 的注意。

于是 IBM 也開始組建團隊來研發自己的消息隊列軟件，這才有了后來的wesphere mq，不久微軟也加入了戰團。

由于商業壁壘，每個軟件廠商都按照自己的標準來實現軟件通信，導致企業客戶不能隨便更換 MQ 平臺。

為了打破這個壁壘，同時為了能夠讓消息在各個消息隊列平臺間互融互通， JMS (Java Message Service) 應運而生 。

JMS 試圖通過提供公共 Java API 的方式，隱藏單獨 MQ 產品供應商提供的實現接口，從而跨越了壁壘，已解決互通問題。

從技術上講， Java 應用程序只需針對 JMS API 進行編程，選擇合適的 MQ 驅動即可， JMS 會打理好其他部分，就好比類似于 JDBC，對于開發者來說，只需要編寫好 sql，具體是使用 oracle 還是 mysql 或者 sqlserver，由具體的廠商來提供驅動包文件即可，開發者無需關心具體的數據庫廠商，從而大大的提升了開發效率、降低了開發難度。

ActiveMQ 就是 JMS 的 一種具體實現。

• JMS - 點對點模型

JMS - 點對點模型

• JMS - 發布訂閱模型

JMS - 發布訂閱模型

盡管使用標準化接口能有效的融合眾多不同的 MQ 產品，但是也暴露出很多問題，例如有些 MQ 產品提供了非常高級的功能，但由于標準化接口的限制，導致用戶無法使用，所以急需一種新的消息通信標準化方案。

在 2006 年 6 月，由 Cisco 、 Redhat 、iMatix 等人聯合制定了 AMQP 的公開標準，由此 AMQP 登上了歷史的舞臺。

AMQP 是應用層協議的一個開放標準，以解決眾多消息中間件的需求和拓撲結構問題，它為面向消息的中間件設計，基于此協議的客戶端與消息中間件可傳遞消息，同時并不受產品、開發語言等條件的限制。

JMS vs AMQP

RabbitMQ 就是 AMQP 的一種具體實現。

AMQP - 模型

隨著時間的推進，雖然 AMQP 規范能適用的業務場景很多，但是 LinkedIn(領英) 在實現消息隊列的時候覺得 AMQP 規范并不適合自己，于是在設計 Kafka 的時候，并不支持 AMQP 所有的特性。

同時阿里巴巴的 RocketMQ 在實現上也借鑒了 Kakfa 的思想，也不支持 AMQP 協議，并且你會發現在 Kafka 和 RocketMQ 中都有類似 Topic 和 Consumer Group 的概念，而這些概念在 AMQP 協議中并不存在。

二、為什么要使用消息隊列

消息中間件雖然發展了很多年，但是不是每個項目都有機會能接觸到消息隊列，對于初次接觸 MQ 的同學，難免會發出一些疑問!

什么是消息隊列?為什么要使用消息隊列?使用消息隊列有哪些弊端?

對于傳統的應用程序，如果需要向另一個應用程序發送信息，只需要向其發出請求即可!

這種方式雖然簡單直接，但是如果應用程序2突然掛了，應用程序1可能會因為服務異常，而無法繼續提供服務!

設想一下，在應用程序1和應用程序2之間，插入一個消息服務，主要用于接受消息和發送消息，這樣應用程序1和應用程序2之間的依賴關系就解耦了，同時也不會因為任何一方當服務不可用時，無法繼續提供服務!

其中插入的消息服務被稱為消息隊列!

由此可見，引入消息隊列帶來的優勢很明顯：

• 程序解耦：應用程序1和應用程序2在進行交互時，不會因為一方服務中斷而導致服務停止;
• 異步處理：程序解耦之后，帶來的最大的好處就是可以異步處理，應用程序1只管把消息發送到消息中間件，應用程序2只需要從消息中間件中接受消息然后進行處理即可;

同時，基于異步處理特性，在某些業務場景下，例如商品秒殺活動，引入消息隊列之后，當客戶端請求量很大的時候，可以有效的進行流量削峰!

如果沒有中間層做緩沖，當進行商品秒殺時，一下突然大量請求涌入，很可能造成系統直接癱瘓，甚至宕機!

在大型網站系統中，如何通過日志快速實時定位系統異常的代碼，可以說至關重要!

LinkedIn 開發的消息隊列 Kafka，可以說是日志采集方面的王者，在中、大型系統開發中，將消息隊列 Kafka 用在日志處理中，可以有效的解決大量日志傳輸的問題。

當然，引入消息隊列也會帶來很明顯的弊端：

• 系統可用性降低：在引入消息隊列之前，你不用考慮消息丟失或者消息隊列服務掛掉等等的情況，但是引入消息隊列之后你就需要去考慮這些問題!
• 系統復雜性提高：加入消息隊列之后，你需要保證消息沒有被重復消費、處理消息沒有被正確處理的情況等等問題!

引入消息隊列雖然會帶來一些問題，俗話說，兵來將擋、水來土掩，這句話同樣適用于 IT 開發者，有坑填坑!

對于系統可用性降低方面，通常常用的解決方案就是搭建消息服務集群，具體技術實現上可以是主從架構或者分布式架構，即時一臺消息隊列服務機器掛了，也不會影響消息隊列無法提供服務!

對于系統復雜性提高方面，常用的解決方案也很多，例如接受者接受到消息之后，可以先將消息寫入數據庫，即時沒有被正確處理，還可以走人工處理，或者消息消費失敗，將消息重新入隊等待下一次消費等等。

三、常見的消息隊列對比

目前比較主流的 MQ 產品，有 ActiveMQ，RabbitMQ，RocketMQ，Kafka，并且他們都是開源的，他們各自也有各自的特點。

總結內容如下

• 1.ActiveMQ 的社區算是比較成熟，但是較目前來說，ActiveMQ 的性能比較差，而且版本迭代很慢，不推薦使用。
• 2.RabbitMQ 在吞吐量方面雖然稍遜于 Kafka 和 RocketMQ ，但是由于它基于 erlang 開發，所以并發能力很強，性能極其好，延時很低，達到微秒級。但是也因為 RabbitMQ 基于 erlang 開發，所以國內很少有公司有實力做erlang源碼級別的研究和定制。如果業務場景對并發量要求不是太高(十萬級、百萬級)，那這四種消息隊列中，首選 RabbitMQ。如果是大數據領域的實時計算、日志采集等場景，用 Kafka 是業內標準的，絕對沒問題，社區活躍度很高，絕對不會黃，何況幾乎是全世界這個領域的事實性規范。
• 3.RocketMQ 阿里出品，Java 系開源項目，源代碼我們可以直接閱讀，然后可以定制自己公司的MQ，并且 RocketMQ 有阿里巴巴的實際業務場景的實戰考驗。RocketMQ 社區活躍度相對較為一般，不過也還可以，文檔相對來說簡單一些。還有就是阿里出臺的技術，你得應對這個技術萬一被拋棄，社區黃掉的風險，如果你們公司有技術實力我覺得用RocketMQ 挺好的。
• 4.Kafka 的特點其實很明顯，就是僅僅提供較少的核心功能，但是提供超高的吞吐量，ms 級的延遲，極高的可用性以及可靠性，而且分布式可以任意擴展。同時 Kafka 最好是支撐較少的 topic 數量即可，保證其超高吞吐量。Kafka 唯一的一點劣勢是有可能消息重復消費，那么對數據準確性會造成極其輕微的影響，在大數據領域中以及日志采集中，這點輕微影響可以忽略。Kafka天然適合大數據實時計算以及日志收集。

四、總結

本文主要對消息隊列的歷史和基礎知識進行梳理和初步介紹，如果有理解不對的地方，望網友批評指出!

五、參考

1、Java工程師面試突擊第1季-中華石杉老師

2、消息中間件的發展史

3、JavaGuide - 消息隊列