一、什么是MQ？

MQ全稱為Message Queue，也就是消息隊列，是應用程序和應用程序之間的通信方法。

二、MQ能用來干什么？

能用來干什么，也就是MQ的適用場景。

在微服務盛行的當下，MQ被使用的也是越來越多，一般常用來進行業務異步解耦、解耦微服務、流量削峰填谷、消息分發、分布式事務的數據一致性，我們分別來看一下。

1、業務異步解耦

在正常業務流程中，比較耗時而且不需要即時返回結果的操作。將這些操作可以做為異步處理，這樣可以大大的加快請求的響應時間。

最常見的場景就是用戶注冊之后，需要發送注冊短信、郵件通知，以告知相關信息。

正常做法，是要經過三大步處理：用戶信息處理、發送郵件、發送短信，等這三步全部都完成之后，才返回前端，告訴你注冊成功了。

使用MQ，只需要在處理完用戶信息之后，給MQ發送兩個消息即可，郵件服務、短信服務監聽MQ的任務消息，根據消息進行發送即可。

2、解耦微服務

還是用戶注冊的例子，將用戶注冊、郵件/短信發送理解為兩個獨立的微服務，就非常好理解。

3、流量削峰填谷

控制流量，也是MQ比較常用的一個場景，一般在秒殺、搞活動中使用廣泛。這個時候一般用戶請求量會激增，可能會遠超當前系統的最大處理量，如果不做任何處理，系統可能就會宕掉。

使用MQ，可以將需要處理的消息全部放入其中，系統按照最大處理能力，去獲取消息進行消費，這樣就可以將一瞬間過來的請求，分散到一段時間內進行處理，避免了系統的崩潰。

4、消息分發

這個也挺常用。多個系統對同一個數據感興趣，只需要監聽同一類消息即可。

例如付款系統，在付款成功之后，正常做法是通知外圍系統這個單子付款成功了，或者是外圍系統定時來拉取付款結果，使用MQ后，付款系統可以在付款成功之后，將消息放到MQ里面，想知道這個結果的系統訂閱這個主題的消息即可，非常方便，也不需要定時去拉取數據了。

5、分布式事務的數據一致性

先說明下，現在有一個專門處理分布式事務的開源框架Seata。在Seata出來之前，涉及到的分布式事務一般都通過消息中間件進行處理。

Seata 是一款開源的分布式事務解決方案，致力于提供高性能和簡單易用的分布式事務服務。Seata 將為用戶提供了 AT、TCC、SAGA 和 XA 事務模式，為用戶打造一站式的分布式解決方案。

目前主流的MQ框架，都支持分布式事務消息，好多小伙伴可能在初次接觸的時候，會很有疑惑，到底是如何保證事務一致性的呢？下圖來自阿里云，說的很明白，有點復雜的流程圖，靜下心來看或者略過不看

事務消息發送步驟如下：

發送方將半事務消息發送至消息隊列RocketMQ。

消息隊列RocketMQ將消息持久化成功之后，向發送方返回Ack確認消息已經發送成功，此時消息為半事務消息。

發送方開始執行本地事務邏輯。

發送方根據本地事務執行結果向服務端提交二次確認（Commit或是Rollback），服務端收到Commit狀態則將半事務消息標記為可投遞，訂閱方最終將收到該消息；服務端收到Rollback狀態則刪除半事務消息，訂閱方將不會接受該消息。

事務消息回查步驟如下：

在斷網或者是應用重啟的特殊情況下，上述步驟4提交的二次確認最終未到達服務端，經過固定時間后服務端將對該消息發起消息回查。

發送方收到消息回查后，需要檢查對應消息的本地事務執行的最終結果。

發送方根據檢查得到的本地事務的最終狀態再次提交二次確認，服務端仍按照步驟4對半事務消息進行操作。

三、有啥缺點

1、系統可用性降低

系統可用性在某種程度上降低。在加入MQ之前，你不用考慮消息丟失或者說MQ掛掉等等的情況，但是，引入MQ之后你就需要去考慮了！

2、系統復雜性提高

加入MQ之后，首先就是你要具備有消息隊列的相關知識，需要保證消息沒有被重復消費、處理消息丟失的情況、保證消息傳遞的順序性等等問題！

3、一致性問題

從上面的使用場景來看，消息隊列帶來的異步確實可以提高系統響應速度。但是，萬一消息的真正消費者并沒有正確消費消息怎么辦？這樣就會導致數據不一致的情況了!

四、總結

MQ的優點很多，但也存在缺點，所以大家還是要根據具體的業務場景來分析是否有必要使用消息中間件。有時候使用簡單的技術可能效果會更好。

目前市面上比較流行的MQ有挺多的，例如：kafka、RocketMQ、RabbitMQ，那他們都有什么優缺點，到底該如何選擇呢？關注公眾號「Hugh的白板」，下篇文章給出答案。

總結

以上是生活随笔為你收集整理的消息队列（MQ）到底能干什么？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。