MQ消息中間件是什么？動力節點小編來為大家解答。

什么是消息中間件

關注于數據的發送和接收，利用高效可靠的異步消息傳遞機制集成分布式系統。通過提供消息傳遞和消息隊列模型，它可以在分布式環境下擴展進程間的通信。

為什么需要消息中間件

1.系統解耦

假設你有個系統A，這個系統A會產出一個核心數據，現在下游有系統B和系統C需要這個數據。

那簡單，系統A就是直接調用系統B和系統C的接口發送數據給他們就好了。

問題：如果現在要是來了系統D、系統E、系統F、系統G，等等，十來個其他系統慢慢的都需要這份核心數據呢?如下圖：

使用MQ后，系統A就把自己的一份核心數據發到MQ里，下游哪個系統感興趣自己去消費即可，不需要了就取消數據的消費，如下圖所示：

2.異步調用

假設你有一個系統調用鏈路，是系統A調用系統B，一般耗時20ms;系統B調用系統C，一般耗時200ms;系統C調用系統D，一般耗時2s，如下圖所示。

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

例如：外賣訂餐，下訂單、付款、賬戶扣款、創建訂單、通知商家給你準備菜品、需要再找個騎手給你送餐。

3.流量削峰

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

但是如下圖所示，在高峰期一下子來了每秒鐘幾千請求，彈指一揮間出現了流量高峰，此時你的選擇是要搞10臺機器，抗住這個瞬時高峰嗎?

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

一旦到了瞬時高峰期，一下涌入每秒幾千的請求，就可以積壓在MQ里面，然后那一臺機器慢慢的處理和消費。

這個就是很典型的一個MQ的用法，用有限的機器資源承載高并發請求，如果業務場景允許異步削峰，高峰期積壓一些請求在MQ里，然后高峰期過了，后臺系統在一定時間內消費完畢不再積壓的話，那就很適合用這種技術方案。

常見的消息中間件有哪些

1.ActiveMQ

Apache下的一個子項目。使用Java完全支持JMS1.1和J2EE 1.4規范的 JMS Provider實現，少量代碼就可以高效地實現高級應用場景。可插拔的傳輸協議支持，比如：in-VM, TCP, SSL, NIO, UDP, multicast, JGroups and JXTA transports。RabbitMQ、ZeroMQ、ActiveMQ均支持常用的多種語言客戶端 C++、Java、.Net,、Python、 Php、 Ruby等。

2.RabbitMQ

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

3.Kafka

Apache下的一個子項目，使用scala實現的一個高性能分布式Publish/Subscribe消息隊列系統，具有以下特性：

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

高吞吐：在一臺普通的服務器上既可以達到10W/s的吞吐速率;

高堆積：支持topic下消費者較長時間離線，消息堆積量大;

完全的分布式系統：Broker、Producer、Consumer都原生自動支持分布式，依賴zookeeper自動實現負載均衡;

支持Hadoop數據并行加載：對于像Hadoop的一樣的日志數據和離線分析系統，但又要求實時處理的限制，這是一個可行的解決方案。

4.RocketMQ

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

具有以下特點：

能夠保證嚴格的消息順序

提供針對消息的過濾功能

提供豐富的消息拉取模式

高效的訂閱者水平擴展能力

實時的消息訂閱機制

億級消息堆積能力

各種MQ之間的比較

以上就是關于“MQ消息中間件詳解”的介紹，大家如果想了解更多相關知識，不妨來關注一下動力節點的ActiveMQ教程，里面有更豐富的知識等著大家去學習，希望對大家能夠有所幫助。