為什么要使用消息隊(duì)列，六個(gè)字總結(jié)：解耦、異步、消峰。

1）解耦

傳統(tǒng)模式下系統(tǒng)間的耦合性太強(qiáng)。怎么說(shuō)呢，舉個(gè)例子：系統(tǒng) A 通過(guò)接口調(diào)用發(fā)送數(shù)據(jù)到 B、C、D 三個(gè)系統(tǒng)，如果將來(lái) E 系統(tǒng)接入或者 B 系統(tǒng)不需要接入了，那么系統(tǒng) A 還需要修改代碼，非常麻煩。

如果系統(tǒng) A 產(chǎn)生了一條比較關(guān)鍵的數(shù)據(jù)，那么它就要時(shí)時(shí)刻刻考慮 B、C、D、E 四個(gè)系統(tǒng)如果掛了該咋辦？這條數(shù)據(jù)它們是否都收到了？顯然，系統(tǒng) A 跟其它系統(tǒng)嚴(yán)重耦合。

而如果我們將數(shù)據(jù)（消息）寫(xiě)入消息隊(duì)列，需要消息的系統(tǒng)直接自己從消息隊(duì)列中消費(fèi)。這樣下來(lái)，系統(tǒng) A 就不需要去考慮要給誰(shuí)發(fā)送數(shù)據(jù)，不需要去維護(hù)這個(gè)代碼，也不需要考慮其他系統(tǒng)是否調(diào)用成功、失敗超時(shí)等情況，反正我只負(fù)責(zé)生產(chǎn)，別的我不管。

2）異步

先來(lái)看傳統(tǒng)同步的情況，舉個(gè)例子：系統(tǒng) A 接收一個(gè)用戶(hù)請(qǐng)求，需要進(jìn)行寫(xiě)庫(kù)操作，還需要同樣的在 B、C、D 三個(gè)系統(tǒng)中進(jìn)行寫(xiě)庫(kù)操作。如果 A 自己本地寫(xiě)庫(kù)只要 1ms，而 B、C、D 三個(gè)系統(tǒng)寫(xiě)庫(kù)分別要 100ms、200ms、300ms。最終請(qǐng)求總延時(shí)是 1 + 100 + 200 + 300 = 601ms，用戶(hù)體驗(yàn)大打折扣。

如果使用消息隊(duì)列，那么系統(tǒng) A 就只需要發(fā)送 3 條消息到消息隊(duì)列中就行了，假如耗時(shí) 5ms，A 系統(tǒng)從接受一個(gè)請(qǐng)求到返回響應(yīng)給用戶(hù)，總時(shí)長(zhǎng)是 1 + 5 = 6ms，對(duì)于用戶(hù)而言，體驗(yàn)好感度直接拉滿。

3）消峰

如果沒(méi)有使用緩存或者消息隊(duì)列，那么系統(tǒng)就是直接基于數(shù)據(jù)庫(kù) MySQL 的，如果有那么一個(gè)高峰期，產(chǎn)生了大量的請(qǐng)求涌入 MySQL，毫無(wú)疑問(wèn)，系統(tǒng)將會(huì)直接崩潰。

那如果我們使用消息隊(duì)列，假設(shè) MySQL 每秒鐘最多處理 1k 條數(shù)據(jù)，而高峰期瞬間涌入了 5k 條數(shù)據(jù)，不過(guò)，這 5k 條數(shù)據(jù)涌入了消息隊(duì)列。這樣，我們的系統(tǒng)就可以從消息隊(duì)列中根據(jù)數(shù)據(jù)庫(kù)的能力慢慢的來(lái)拉取請(qǐng)求，不要超過(guò)自己每秒能處理的最大請(qǐng)求數(shù)量就行。

也就是說(shuō)消息隊(duì)列每秒鐘 5k 個(gè)請(qǐng)求進(jìn)來(lái)，1k 個(gè)請(qǐng)求出去，假設(shè)高峰期 1 個(gè)小時(shí)，那么這段時(shí)間就可能有幾十萬(wàn)甚至幾百萬(wàn)的請(qǐng)求積壓在消息隊(duì)列中。不過(guò)這個(gè)短暫的高峰期積壓是完全可以的，因?yàn)楦叻迤谶^(guò)了之后，每秒鐘就沒(méi)有那么多的請(qǐng)求進(jìn)入消息隊(duì)列了，但是數(shù)據(jù)庫(kù)依然會(huì)按照每秒 1k 個(gè)請(qǐng)求的速度處理。所以只要高峰期一過(guò)，系統(tǒng)就會(huì)快速的將積壓的消息給處理掉。