MQ消息中間件是什么？動(dòng)力節(jié)點(diǎn)小編來為大家解答。

什么是消息中間件

關(guān)注于數(shù)據(jù)的發(fā)送和接收，利用高效可靠的異步消息傳遞機(jī)制集成分布式系統(tǒng)。通過提供消息傳遞和消息隊(duì)列模型，它可以在分布式環(huán)境下擴(kuò)展進(jìn)程間的通信。

為什么需要消息中間件

1.系統(tǒng)解耦

假設(shè)你有個(gè)系統(tǒng)A，這個(gè)系統(tǒng)A會(huì)產(chǎn)出一個(gè)核心數(shù)據(jù)，現(xiàn)在下游有系統(tǒng)B和系統(tǒng)C需要這個(gè)數(shù)據(jù)。

那簡單，系統(tǒng)A就是直接調(diào)用系統(tǒng)B和系統(tǒng)C的接口發(fā)送數(shù)據(jù)給他們就好了。

問題：如果現(xiàn)在要是來了系統(tǒng)D、系統(tǒng)E、系統(tǒng)F、系統(tǒng)G，等等，十來個(gè)其他系統(tǒng)慢慢的都需要這份核心數(shù)據(jù)呢?如下圖：

使用MQ后，系統(tǒng)A就把自己的一份核心數(shù)據(jù)發(fā)到MQ里，下游哪個(gè)系統(tǒng)感興趣自己去消費(fèi)即可，不需要了就取消數(shù)據(jù)的消費(fèi)，如下圖所示：

2.異步調(diào)用

假設(shè)你有一個(gè)系統(tǒng)調(diào)用鏈路，是系統(tǒng)A調(diào)用系統(tǒng)B，一般耗時(shí)20ms;系統(tǒng)B調(diào)用系統(tǒng)C，一般耗時(shí)200ms;系統(tǒng)C調(diào)用系統(tǒng)D，一般耗時(shí)2s，如下圖所示。

用戶請求走完整個(gè)鏈路需要耗費(fèi)：20ms + 200ms + 2000ms(2s) = 2220ms，

例如：外賣訂餐，下訂單、付款、賬戶扣款、創(chuàng)建訂單、通知商家給你準(zhǔn)備菜品、需要再找個(gè)騎手給你送餐。

3.流量削峰

假設(shè)你有一個(gè)系統(tǒng)，平時(shí)正常的時(shí)候每秒可能就幾百個(gè)請求，系統(tǒng)部署在8核16G的機(jī)器的上，正常處理都是OK的，每秒幾百請求是可以輕松抗住的，

但是如下圖所示，在高峰期一下子來了每秒鐘幾千請求，彈指一揮間出現(xiàn)了流量高峰，此時(shí)你的選擇是要搞10臺(tái)機(jī)器，抗住這個(gè)瞬時(shí)高峰嗎?

此時(shí)我們就可以用MQ中間件來進(jìn)行流量削峰。所有機(jī)器前面部署一層MQ，平時(shí)每秒幾百請求大家都可以輕松接收消息。

一旦到了瞬時(shí)高峰期，一下涌入每秒幾千的請求，就可以積壓在MQ里面，然后那一臺(tái)機(jī)器慢慢的處理和消費(fèi)。

這個(gè)就是很典型的一個(gè)MQ的用法，用有限的機(jī)器資源承載高并發(fā)請求，如果業(yè)務(wù)場景允許異步削峰，高峰期積壓一些請求在MQ里，然后高峰期過了，后臺(tái)系統(tǒng)在一定時(shí)間內(nèi)消費(fèi)完畢不再積壓的話，那就很適合用這種技術(shù)方案。

常見的消息中間件有哪些

1.ActiveMQ

Apache下的一個(gè)子項(xiàng)目。使用Java完全支持JMS1.1和J2EE 1.4規(guī)范的 JMS Provider實(shí)現(xiàn)，少量代碼就可以高效地實(shí)現(xiàn)高級(jí)應(yīng)用場景?？刹灏蔚膫鬏攨f(xié)議支持，比如：in-VM, TCP, SSL, NIO, UDP, multicast, JGroups and JXTA transports。RabbitMQ、ZeroMQ、ActiveMQ均支持常用的多種語言客戶端 C++、Java、.Net,、Python、 Php、 Ruby等。

2.RabbitMQ

使用Erlang編寫的一個(gè)開源的消息隊(duì)列，本身支持很多的協(xié)議：AMQP，XMPP, SMTP,STOMP，也正是如此，使的它變的非常重量級(jí)，更適合于企業(yè)級(jí)的開發(fā)。同時(shí)實(shí)現(xiàn)了Broker架構(gòu)，核心思想是生產(chǎn)者不會(huì)將消息直接發(fā)送給隊(duì)列，消息在發(fā)送給客戶端時(shí)先在中心隊(duì)列排隊(duì)。對(duì)路由(Routing)，負(fù)載均衡(Load balance)、數(shù)據(jù)持久化都有很好的支持。多用于進(jìn)行企業(yè)級(jí)的ESB整合。

3.Kafka

Apache下的一個(gè)子項(xiàng)目，使用scala實(shí)現(xiàn)的一個(gè)高性能分布式Publish/Subscribe消息隊(duì)列系統(tǒng)，具有以下特性：

快速持久化：通過磁盤順序讀寫與零拷貝機(jī)制，可以在O(1)的系統(tǒng)開銷下進(jìn)行消息持久化;

高吞吐：在一臺(tái)普通的服務(wù)器上既可以達(dá)到10W/s的吞吐速率;

高堆積：支持topic下消費(fèi)者較長時(shí)間離線，消息堆積量大;

完全的分布式系統(tǒng)：Broker、Producer、Consumer都原生自動(dòng)支持分布式，依賴zookeeper自動(dòng)實(shí)現(xiàn)負(fù)載均衡;

支持Hadoop數(shù)據(jù)并行加載：對(duì)于像Hadoop的一樣的日志數(shù)據(jù)和離線分析系統(tǒng)，但又要求實(shí)時(shí)處理的限制，這是一個(gè)可行的解決方案。

4.RocketMQ

阿里系下開源的一款分布式、隊(duì)列模型的消息中間件，原名Metaq，3.0版本名稱改為RocketMQ，是阿里參照kafka設(shè)計(jì)思想使用java實(shí)現(xiàn)的一套mq。同時(shí)將阿里系內(nèi)部多款mq產(chǎn)品(Notify、metaq)進(jìn)行整合，只維護(hù)核心功能，去除了所有其他運(yùn)行時(shí)依賴，保證核心功能最簡化，在此基礎(chǔ)上配合阿里上述其他開源產(chǎn)品實(shí)現(xiàn)不同場景下mq的架構(gòu)，目前主要多用于訂單交易系統(tǒng)。

具有以下特點(diǎn)：

能夠保證嚴(yán)格的消息順序

提供針對(duì)消息的過濾功能

提供豐富的消息拉取模式

高效的訂閱者水平擴(kuò)展能力

實(shí)時(shí)的消息訂閱機(jī)制

億級(jí)消息堆積能力

各種MQ之間的比較

以上就是關(guān)于“MQ消息中間件詳解”的介紹，大家如果想了解更多相關(guān)知識(shí)，不妨來關(guān)注一下動(dòng)力節(jié)點(diǎn)的ActiveMQ教程，里面有更豐富的知識(shí)等著大家去學(xué)習(xí)，希望對(duì)大家能夠有所幫助。