我們不會平白無故引入一個技術棧，一定是看重它的某些特性，畢竟引入一個技術可能存在弊端和風險。我們在談論為什么使用消息隊列的時候一定要根據具體業務來，比如在實際業務中遇到了什么困難，如果不使用消息隊列就很棘手，通過使用消息后解決了哪些問題。這里總結了三點比較核心原因：解耦、異步、削峰。

解耦

在某個場景下，A系統需要向BCD系統通過接口調用發送一條數據過去，這個時候E系統也要數據，D系統也要數據，此時A系統內心肯定是崩潰的。

上訴場景中A系統和其他系統耦合性很高，每當產生一條數據的時候A系統都要考慮到其他系統是否在線？是否掛掉？是否接收正常？所以A系統真的是太難了！

如果使用MQ，A系統產生一條數據后就放進MQ，其他系統需要就自己到MQ系統中去消費，不需要就可以取消對該消息的訂閱，A系統壓根不需要再考慮給其他系統發送數據的各種亂七八糟問題。

總結：通過一個MQ，Pub/Sub發布訂閱消息這么一個模型，A系統就跟其它系統徹底解耦了。

異步

在某場景下，A系統收到一條數據后需要在自己本地寫庫，同時還要在BCD三個系統寫庫，自己本地寫庫要3ms，BCD三個系統分別寫庫要300ms、450ms、200ms。總共要延時3+300+450+200=953ms，接近1s啊，對強迫癥的人來說簡直要爆炸！

正常一個請求控制在２００ｍｓ左右，客戶是沒有感知的。

如果使用MQ，那么A系統連續發送3條消息到MQ隊列中，假如耗時5ms，A系統從接受一個請求到返回響應給用戶，總時長是3+5=8ms，對于用戶而言，其實感覺上就是點個按鈕，8ms以后就直接返回了，爽！網站做得真好，真快！美滋滋！

削峰

每天0:00到12:00，A系統風平浪靜，每秒并發請求數量就50個。結果每次一到12:00~13:00，每秒并發請求數量突然會暴增到5k+條。但是系統是直接基于MySQL的，大量的請求涌入MySQL，每秒鐘對MySQL執行約5k條SQL。

一般的MySQL，扛到每秒2k個請求就差不多了，如果每秒請求到5k的話，可能就直接把MySQL給打死了，導致系統崩潰，用戶也就沒法再使用系統了。但是高峰期一過，到了下午的時候，就成了低峰期，可能也就1w的用戶同時在網站上操作，每秒中的請求數量可能也就50個請求，對整個系統幾乎沒有任何的壓力。

如果使用MQ，每秒5k個請求寫入MQ，A系統每秒鐘最多處理2k個請求，因為MySQL每秒鐘最多處理2k個。A系統從MQ中慢慢拉取請求，每秒鐘就拉取2k個請求，不要超過自己每秒能處理的最大請求數量就ok，這樣下來，哪怕是高峰期的時候，A系統也絕對不會掛掉。而MQ每秒鐘5k個請求進來，就2k個請求出去，結果就導致在中午高峰期（1個小時），可能有幾十萬甚至幾百萬的請求積壓在MQ中。

這個短暫的高峰期積壓是ok的，因為高峰期過了之后，每秒鐘就50個請求進MQ，但是A系統依然會按照每秒2k個請求的速度在處理。所以說，只要高峰期一過，A系統就會快速將積壓的消息給解決掉。

消息隊列的缺點

上面吹了消息隊列的一堆優點，但是也不能不知道使用它帶來的一些缺點吧！缺點有以下幾點：

• 系統可用性降低

系統引入的外部依賴越多，越容易掛掉。本來你就是A系統調用BCD三個系統的接口就好了，人ABCD四個系統好好的，沒啥問題，你偏加個MQ進來，萬一MQ掛了咋整，MQ一掛，整套系統崩潰的，你不就完了？

• 系統復雜度提高

硬生生加個MQ進來，你怎么保證消息沒有重復消費？怎么處理消息丟失情況？怎么保證消息傳遞的順序性？頭大頭大，問題一大堆，痛苦不已。

• 一致性問題

A系統處理完了直接返回成功了，人都以為你這個請求就成功了；但是問題是，要是BCD三個系統那里，BD兩個系統寫庫成功了，結果C系統寫庫失敗了，咋整？你這數據就不一致了。

所以消息隊列實際是一種非常復雜的架構，你引入它有很多好處，但是也得針對它帶來的壞處做各種額外的技術方案和架構來規避掉，做好之后，你會發現，媽呀，系統復雜度提升了一個數量級，也許是復雜了10倍。但是關鍵時刻，用，還是得用的。

以上就是動力節點小編介紹的"消息隊列MQ詳解"，希望對大家有幫助，想了解更多可查看Java教程。動力節點在線學習教程，針對沒有任何Java基礎的讀者學習,讓你從入門到精通,主要介紹了一些Java基礎的核心知識，讓同學們更好更方便的學習和了解Java編程，感興趣的同學可以關注一下。