[[345260]]

什么是消息中間件?

消息中間件屬于分布式系統(tǒng)中的一個子系統(tǒng)，關(guān)注于數(shù)據(jù)的發(fā)送和接收，利用高效可靠的消息傳遞機制對分布式系統(tǒng)中的其余各個子系統(tǒng)經(jīng)進行集成

消息中間件的使用場景

1.異步處理非核心流程異步化，提高系統(tǒng)響應(yīng)性能

原來用戶注冊一下可能得依次寫數(shù)據(jù)庫，發(fā)送郵件和短信后，才能提示用戶注冊成功

現(xiàn)在只要寫數(shù)據(jù)庫，寫消息隊列后就直接提示用戶注冊成功，發(fā)送郵件和短信是異步處理，提高了響應(yīng)速度

2.應(yīng)用解耦

系統(tǒng)不是強耦合，消息接受者可以隨意增加，而不需要修改消息發(fā)送者的代碼。消息發(fā)送者的成功不依賴消息接受者

rpc實現(xiàn)

消息隊列實現(xiàn)

如果庫存系統(tǒng)出了問題，用戶就不能正常下單，這是不合理的。可以通過消息隊列來解耦。

當(dāng)有新的系統(tǒng)如廣告系統(tǒng)對用戶的訂單也感興趣的時候，只需要從消息隊列中拿消息即可，訂單系統(tǒng)完全不用改變

3.流量削峰

當(dāng)上下游系統(tǒng)處理能力存在差距的時候，可以用消息隊列進行緩沖

在這里插入圖片描述

當(dāng)有秒殺業(yè)務(wù)時，一下有大量請求涌入時，很可能造成系統(tǒng)癱瘓，此時可以用消息隊列緩沖一下

4.日志處理

將消息隊列用在日志處理中，比如Kafka可以用來解決大量日志傳輸?shù)膯栴}

5.消息通訊

消息隊列一般都內(nèi)置了高效的通信機制，因此也可以用于單純的消息通訊，比如實現(xiàn)點對點消息隊列或者聊天室等

消息中間件編年史

初見曙光

1.消息中間件其實誕生的很早，在互聯(lián)網(wǎng)應(yīng)用還是一片荒蕪的年代，有個在美國的印度哥們Vivek Ranadive就設(shè)想了一種通用軟件總線，采用發(fā)布訂閱的模式，像主板上的總線一樣供其他相應(yīng)程序接入。他創(chuàng)辦了一家公司Teknekron，實現(xiàn)了世界上第一個消息中間件The Information Bus(TIB)

各自為戰(zhàn)

2.TIB受到了企業(yè)的歡迎，Teknekron的業(yè)務(wù)發(fā)展引起了當(dāng)時最牛氣的IT公司IBM的注意，于是他們也開始研發(fā)了自己消息隊列軟件，于是才有了后來的wesphere mq，微軟也陸續(xù)加入了戰(zhàn)團。由于商業(yè)壁壘，商業(yè)MQ供應(yīng)商想要解決應(yīng)用應(yīng)用互通的問題，而不是去創(chuàng)建標(biāo)準(zhǔn)來實現(xiàn)不同MQ產(chǎn)品間的互通，或者允許應(yīng)用程序更改MQ平臺

劫制天下

3.為了打破這個壁壘，同時為了能夠讓消息在各個消息隊列平臺間互融互通， JMS (Java Message Service) 應(yīng)運而生 。JMS 試圖通過提供公共 Java API 的方式，隱藏單獨 MQ 產(chǎn)品供應(yīng) 商提供的實際接口，從而跨越了壁壘，以及解決了互通問題。從技術(shù)上講， Java 應(yīng)用程序只需 針對 JMS API 編程，選擇合適的 MQ 驅(qū)動即可， JMS 會打理好其他部分 。ActiveMQ 就是 JMS 的 一種實現(xiàn) 。不過嘗試使用單獨標(biāo)準(zhǔn)化接口來膠合眾多不同的接口，最終會暴露出問題，使得 應(yīng)用程序變得更加脆弱 。所以急需一種新的消息通信標(biāo)準(zhǔn)化方案 。

一統(tǒng)江湖

4.在 2006 年 6 月，由 Cisco 、 Redhat 、iMatix 等聯(lián)合制定了 AMQP 的公開標(biāo)準(zhǔn)，由此 AMQP 登上了歷史的舞臺 。它是應(yīng)用層協(xié)議的一個開放標(biāo)準(zhǔn)，以解決眾多消息中間件的需求和拓撲結(jié) 構(gòu)問題 。它為面向消息的中間件設(shè)計，基于此協(xié)議的客戶端與消息中間件可傳遞消息，并不受 產(chǎn)品、開發(fā)語言等條件的限制 。

合久必分

5.LinkedIn在實現(xiàn)消息隊列的時候覺得AMQP規(guī)范并不適合自己，所以Kafka并不支持AMQP協(xié)議。RocketMQ在實現(xiàn)上借鑒了Kakfa的思想，所以也不支持AMQP協(xié)議，并且你會發(fā)現(xiàn)在Kafka和RocketMQ中都有類似Topic和Consumer Group的概念，而這些概念在AMQP協(xié)議中是不存在的

如何選擇消息中間件

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

消息模型

如果讓你設(shè)計一個消息隊列?你會怎么實現(xiàn)呢?

可能你立馬就會想到用隊列，一邊放，一邊取。這其實就是消息隊列常見的一種消息模型，隊列模型

所以一個簡單的消息隊列用Redis中的List就能實現(xiàn)。當(dāng)然Redis5.0版本之后針對消息隊列這種場景專門設(shè)計了一個數(shù)據(jù)結(jié)構(gòu)Streams。

隊列模型有哪些缺點呢?

如果將一類消息發(fā)送給不同的消費者，每個消費者都要接收全量的消息，此時就很不方便。因為你要將相同的消息發(fā)送到不同的隊列，多一個消費者就得多發(fā)一份隊列。這樣生產(chǎn)者必須知道有多少個消費者，不利于解耦。

那么該如何解決這個問題呢?

想想RabbitMQ的結(jié)構(gòu)圖

RabbitMQ并不是直接把消息發(fā)送到隊列中的，而是發(fā)送到Exchange中，Exchange和Queue進行關(guān)聯(lián)，消息由Exchange根據(jù)規(guī)則發(fā)送到對應(yīng)的隊列。這樣生產(chǎn)者和消費者完成了解耦。

還有哪種方式能解決這種多消費者的問題呢?

答對了，就是發(fā)布訂閱模型

RocketMQ和Kafka都是基于發(fā)布訂閱模型實現(xiàn)的，RocketMQ的消息模型圖如下

生產(chǎn)者是發(fā)布者，消費者是訂閱者，消息是主題

為了提高消費的并行度，一類消息會被分發(fā)到多個隊列中，在RocketMQ中叫Queue，在Kafka中叫做Partition(分區(qū))，都是類似的概念。

AMQP協(xié)議詳解

前面說到消息中間件有2種協(xié)議，JMS和AMQP。JMS你可以類比為JDBC，搞了一套接口讓不同廠商來實現(xiàn)這個接口，但是這個協(xié)議設(shè)計的確實不夠優(yōu)雅，因此就不介紹這個協(xié)議了，除非你用ActiveMQ，不然學(xué)了真沒啥用。詳細說一下AMQP協(xié)議，畢竟現(xiàn)在用RabbitMQ的公司還是很多的，要想學(xué)好RabbitMQ，AMQP協(xié)議是必須要清楚的。

AMQP協(xié)議模型

上圖是AMQP協(xié)議中一個消息的流轉(zhuǎn)過程，畫的的很清楚，不詳細介紹了。

AMQP核心概念介紹一些AMQP協(xié)議常見的概念。

概念解釋

如果有用過ActiveMQ和RabbitMQ，對上面的名詞一定不會陌生。后面一篇文章就結(jié)合RabbitMQ來闡述上面的概念。

本文轉(zhuǎn)載自微信公眾號「Java識堂」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系Java識堂公眾號。