mq簡(jiǎn)介
mq 就是消息隊(duì)列（Message Queue）。想必大家對(duì)隊(duì)列的數(shù)據(jù)結(jié)構(gòu)已經(jīng)很熟悉了，消息隊(duì)列可以簡(jiǎn)單理解為：把要傳輸?shù)臄?shù)據(jù)放在隊(duì)列中，mq 就是存放和發(fā)送消息的這么一個(gè)隊(duì)列中間件。在消息隊(duì)列中，把數(shù)據(jù)放到消息隊(duì)列的角色叫做 生產(chǎn)者，從消息隊(duì)列中消費(fèi)獲取數(shù)據(jù)的叫做 消費(fèi)者。
那么消息隊(duì)列有哪些使用場(chǎng)景呢? 六字真言：異步削峰解耦。
MQ的異步
異步概念想必大家都熟悉了，就是 a應(yīng)用（或程序） 將數(shù)據(jù)傳遞給b應(yīng)用（或程序）后，不等待b的響應(yīng)結(jié)果直接做下一步動(dòng)作，而b并行執(zhí)行，提高效率。使用mq，就能完美支持異步：a將數(shù)據(jù)發(fā)送到mq，然后自己該干嘛干嘛，b監(jiān)聽mq的消息，來了消息就消費(fèi)它。這樣就做到程序或者應(yīng)用間的異步。
mq的削峰
首先我們要知道什么是削峰：削峰的全稱應(yīng)該叫削峰填谷。削峰就是當(dāng)應(yīng)用或者程序的請(qǐng)求量過大的時(shí)候，將一部分請(qǐng)求延時(shí)處理，放到請(qǐng)求量不大時(shí)間段去處理它。mq削峰填谷的原理也很簡(jiǎn)單，mq在應(yīng)用程序中相當(dāng)于一個(gè) “蓄水池” 的作用——當(dāng) “水流量（請(qǐng)求）” 過大的時(shí)候，“蓄水池（mq）” 將 "水" 先存起來。當(dāng)有能力去消費(fèi)這些水的時(shí)候再去從 “蓄水池” 放水。實(shí)際的過程是——請(qǐng)求數(shù)據(jù)先發(fā)到 mq ，應(yīng)用程序監(jiān)聽mq 并消費(fèi)消息。當(dāng)請(qǐng)求量大于消費(fèi)量的時(shí)候，請(qǐng)求積壓在mq中存儲(chǔ)；當(dāng)消費(fèi)量大于請(qǐng)求量的時(shí)候，請(qǐng)求就會(huì)慢慢被處理完。這聽上去就像小學(xué)做的游泳池放水排水的數(shù)學(xué)題。
mq的解耦
mq解耦性是顯而易見的，應(yīng)用程序直接不直接互相耦合，甚至可以不用知道對(duì)方的存在。它想要發(fā)出什么樣的請(qǐng)求，或者拿什么數(shù)據(jù)，都是去找mq。mq就像個(gè)搬運(yùn)工一樣在這些應(yīng)用之間搬運(yùn)數(shù)據(jù)。
mq 協(xié)議及產(chǎn)品
mq 協(xié)議有兩種，jms 和 AMQP 。通常而言提到JMS（Java MessageService）實(shí)際上是指 JMS API 。JMS 是由Sun公司早期提出的消息標(biāo)準(zhǔn)，旨在為java應(yīng)用提供統(tǒng)一的消息操作，包括create、send、receive
等。JMS已經(jīng)成為 Java Enterprise Edition 的一部分。從使用角度看，JMS和JDBC擔(dān)任差不多的角色，用戶都是根據(jù)相應(yīng)的接口可以和實(shí)現(xiàn)了 JMS 的服務(wù)進(jìn)行通信，進(jìn)行相關(guān)的操作。
JMS角色概念：
JMS provider：實(shí)現(xiàn)了JMS接口的消息中間件，如ActiveMQ
JMS client：生產(chǎn)或者消費(fèi)消息的應(yīng)用
JMS producer/publisher：JMS消息生產(chǎn)者
JMS consumer/subscriber ：JMS消息消費(fèi)者
JMS message：消息，在各個(gè)JMS client傳輸?shù)膶?duì)象；
JMS queue：Provider存放等待被消費(fèi)的消息的地方
JMS topic：一種提供多個(gè)訂閱者消費(fèi)消息的一種機(jī)制；在MQ中常常被提到，topic模式。
AMQP（advanced message queuing protocol） 在2003年時(shí)被提出，最早用于解決金融領(lǐng)不同平臺(tái)之間的消息傳遞交互問題。AMQP是一種 binary wire-level protocol（鏈接協(xié)議）。AMQP 不從 API 的層面層對(duì)使用規(guī)范進(jìn)行限定，而是直接定義網(wǎng)絡(luò)交換的數(shù)據(jù)格式。這意味著實(shí)現(xiàn)了amqp協(xié)議的消息隊(duì)列中間件支持跨平臺(tái)。我們可以使用 Java 的 AMQP provider 而 consumer 可以是golang 。
在AMQP中，消息路由（messagerouting）和JMS存在一些差別，在AMQP中增加了 Exchange 和 binding 的角色。producer 將消息發(fā)送給 Exchange ，binding 決定 Exchange 的消息應(yīng)該發(fā)送到那個(gè) queue，而consumer直接從queue中消費(fèi)消息。queue和exchange的bind有consumer來決定。
相對(duì)而言，AMQP的消息隊(duì)列使用的更為廣泛。如 rabbitMQ , kafka , rocketMQ 等都是實(shí)現(xiàn)AMQP協(xié)議的消息隊(duì)列。接下來我們將會(huì)學(xué)習(xí) rabbitMQ 和 kafka 的相關(guān)知識(shí)。
