我們不會(huì)平白無故引入一個(gè)技術(shù)棧，一定是看重它的某些特性，畢竟引入一個(gè)技術(shù)可能存在弊端和風(fēng)險(xiǎn)。我們?cè)谡務(wù)摓槭裁词褂孟㈥?duì)列的時(shí)候一定要根據(jù)具體業(yè)務(wù)來，比如在實(shí)際業(yè)務(wù)中遇到了什么困難，如果不使用消息隊(duì)列就很棘手，通過使用消息后解決了哪些問題。這里總結(jié)了三點(diǎn)比較核心原因：解耦、異步、削峰。

解耦

在某個(gè)場(chǎng)景下，A系統(tǒng)需要向BCD系統(tǒng)通過接口調(diào)用發(fā)送一條數(shù)據(jù)過去，這個(gè)時(shí)候E系統(tǒng)也要數(shù)據(jù)，D系統(tǒng)也要數(shù)據(jù)，此時(shí)A系統(tǒng)內(nèi)心肯定是崩潰的。

上訴場(chǎng)景中A系統(tǒng)和其他系統(tǒng)耦合性很高，每當(dāng)產(chǎn)生一條數(shù)據(jù)的時(shí)候A系統(tǒng)都要考慮到其他系統(tǒng)是否在線？是否掛掉？是否接收正常？所以A系統(tǒng)真的是太難了！

如果使用MQ，A系統(tǒng)產(chǎn)生一條數(shù)據(jù)后就放進(jìn)MQ，其他系統(tǒng)需要就自己到MQ系統(tǒng)中去消費(fèi)，不需要就可以取消對(duì)該消息的訂閱，A系統(tǒng)壓根不需要再考慮給其他系統(tǒng)發(fā)送數(shù)據(jù)的各種亂七八糟問題。

總結(jié)：通過一個(gè)MQ，Pub/Sub發(fā)布訂閱消息這么一個(gè)模型，A系統(tǒng)就跟其它系統(tǒng)徹底解耦了。

異步

在某場(chǎng)景下，A系統(tǒng)收到一條數(shù)據(jù)后需要在自己本地寫庫(kù)，同時(shí)還要在BCD三個(gè)系統(tǒng)寫庫(kù)，自己本地寫庫(kù)要3ms，BCD三個(gè)系統(tǒng)分別寫庫(kù)要300ms、450ms、200ms。總共要延時(shí)3+300+450+200=953ms，接近1s啊，對(duì)強(qiáng)迫癥的人來說簡(jiǎn)直要爆炸！

正常一個(gè)請(qǐng)求控制在２００ｍｓ左右，客戶是沒有感知的。

如果使用MQ，那么A系統(tǒng)連續(xù)發(fā)送3條消息到MQ隊(duì)列中，假如耗時(shí)5ms，A系統(tǒng)從接受一個(gè)請(qǐng)求到返回響應(yīng)給用戶，總時(shí)長(zhǎng)是3+5=8ms，對(duì)于用戶而言，其實(shí)感覺上就是點(diǎn)個(gè)按鈕，8ms以后就直接返回了，爽！網(wǎng)站做得真好，真快！美滋滋！

削峰

每天0:00到12:00，A系統(tǒng)風(fēng)平浪靜，每秒并發(fā)請(qǐng)求數(shù)量就50個(gè)。結(jié)果每次一到12:00~13:00，每秒并發(fā)請(qǐng)求數(shù)量突然會(huì)暴增到5k+條。但是系統(tǒng)是直接基于MySQL的，大量的請(qǐng)求涌入MySQL，每秒鐘對(duì)MySQL執(zhí)行約5k條SQL。

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

如果使用MQ，每秒5k個(gè)請(qǐng)求寫入MQ，A系統(tǒng)每秒鐘最多處理2k個(gè)請(qǐng)求，因?yàn)镸ySQL每秒鐘最多處理2k個(gè)。A系統(tǒng)從MQ中慢慢拉取請(qǐng)求，每秒鐘就拉取2k個(gè)請(qǐng)求，不要超過自己每秒能處理的最大請(qǐng)求數(shù)量就ok，這樣下來，哪怕是高峰期的時(shí)候，A系統(tǒng)也絕對(duì)不會(huì)掛掉。而MQ每秒鐘5k個(gè)請(qǐng)求進(jìn)來，就2k個(gè)請(qǐng)求出去，結(jié)果就導(dǎo)致在中午高峰期（1個(gè)小時(shí)），可能有幾十萬甚至幾百萬的請(qǐng)求積壓在MQ中。

這個(gè)短暫的高峰期積壓是ok的，因?yàn)楦叻迤谶^了之后，每秒鐘就50個(gè)請(qǐng)求進(jìn)MQ，但是A系統(tǒng)依然會(huì)按照每秒2k個(gè)請(qǐng)求的速度在處理。所以說，只要高峰期一過，A系統(tǒng)就會(huì)快速將積壓的消息給解決掉。

消息隊(duì)列的缺點(diǎn)

上面吹了消息隊(duì)列的一堆優(yōu)點(diǎn)，但是也不能不知道使用它帶來的一些缺點(diǎn)吧！缺點(diǎn)有以下幾點(diǎn)：

• 系統(tǒng)可用性降低

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

• 系統(tǒng)復(fù)雜度提高

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

• 一致性問題

A系統(tǒng)處理完了直接返回成功了，人都以為你這個(gè)請(qǐng)求就成功了；但是問題是，要是BCD三個(gè)系統(tǒng)那里，BD兩個(gè)系統(tǒng)寫庫(kù)成功了，結(jié)果C系統(tǒng)寫庫(kù)失敗了，咋整？你這數(shù)據(jù)就不一致了。

所以消息隊(duì)列實(shí)際是一種非常復(fù)雜的架構(gòu)，你引入它有很多好處，但是也得針對(duì)它帶來的壞處做各種額外的技術(shù)方案和架構(gòu)來規(guī)避掉，做好之后，你會(huì)發(fā)現(xiàn)，媽呀，系統(tǒng)復(fù)雜度提升了一個(gè)數(shù)量級(jí)，也許是復(fù)雜了10倍。但是關(guān)鍵時(shí)刻，用，還是得用的。

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