1. 系統(tǒng)解耦

看這么個場景。A 系統(tǒng)發(fā)送數(shù)據(jù)到 BCD 三個系統(tǒng)，通過接口調(diào)用發(fā)送。如果 E 系統(tǒng)也要這個數(shù)據(jù)呢？那如果 C 系統(tǒng)現(xiàn)在不需要了呢？A 系統(tǒng)負(fù)責(zé)人幾乎崩潰......

在這個場景中，A 系統(tǒng)跟其它各種亂七八糟的系統(tǒng)嚴(yán)重耦合，A 系統(tǒng)產(chǎn)生一條比較關(guān)鍵的數(shù)據(jù)，很多系統(tǒng)都需要 A 系統(tǒng)將這個數(shù)據(jù)發(fā)送過來。A 系統(tǒng)要時時刻刻考慮 BCDE 四個系統(tǒng)如果掛了該咋辦？要不要重發(fā)，要不要把消息存起來？頭發(fā)都白了啊！

如果使用 MQ，A 系統(tǒng)產(chǎn)生一條數(shù)據(jù)，發(fā)送到 MQ 里面去，哪個系統(tǒng)需要數(shù)據(jù)自己去 MQ 里面消費。如果新系統(tǒng)需要數(shù)據(jù)，直接從 MQ 里消費即可；如果某個系統(tǒng)不需要這條數(shù)據(jù)了，就取消對 MQ 消息的消費即可。這樣下來，A 系統(tǒng)壓根兒不需要去考慮要給誰發(fā)送數(shù)據(jù)，不需要維護(hù)這個代碼，也不需要考慮人家是否調(diào)用成功、失敗超時等情況。

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

因此，我們需要去考慮一下我們的業(yè)務(wù)系統(tǒng)中是否有類似的場景，就是一個系統(tǒng)或者一個模塊，調(diào)用了多個系統(tǒng)或者模塊，互相之間的調(diào)用很復(fù)雜，維護(hù)起來很麻煩。但是其實這個調(diào)用是不需要直接同步調(diào)用接口的，如果用 MQ 給它異步化解耦，也是可以的，你就需要去考慮在你的項目里，是不是可以運(yùn)用這個 MQ 去進(jìn)行系統(tǒng)的解耦。

2. 異步處理

再來看一個場景，A 系統(tǒng)接收一個請求，需要在自己本地寫庫，還需要在 BCD 三個系統(tǒng)寫庫，自己本地寫庫要 3ms，BCD 三個系統(tǒng)分別寫庫要 300ms、450ms、200ms。最終請求總延時是 3 + 300 + 450 + 200 = 953ms，接近 1s，用戶感覺搞個什么東西，慢死了慢死了。用戶通過瀏覽器發(fā)起請求，等待個 1s，這幾乎是不可接受的。

一般互聯(lián)網(wǎng)類的企業(yè)，對于用戶直接的操作，一般要求是每個請求都必須在 200 ms 以內(nèi)完成，對用戶幾乎是無感知的。

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

3. 流量削峰

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

一般的 MySQL，扛到每秒 2k 個請求就差不多了，如果每秒請求到 5k 的話，可能就直接把 MySQL 給打死了，導(dǎo)致系統(tǒng)崩潰，用戶也就沒法再使用系統(tǒng)了。

但是高峰期一過，到了下午的時候，就成了低峰期，可能也就 1w 的用戶同時在網(wǎng)站上操作，每秒中的請求數(shù)量可能也就 50 個請求，對整個系統(tǒng)幾乎沒有任何的壓力。

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