這篇文章主要介紹了數(shù)據(jù)庫為什么要用消息隊列的相關(guān)知識，內(nèi)容詳細(xì)易懂，操作簡單快捷，具有一定借鑒價值，相信大家閱讀完這篇數(shù)據(jù)庫為什么要用消息隊列文章都會有所收獲，下面我們一起來看看吧。

目前創(chuàng)新互聯(lián)公司已為上千家的企業(yè)提供了網(wǎng)站建設(shè)、域名、虛擬主機(jī)、網(wǎng)站托管維護(hù)、企業(yè)網(wǎng)站設(shè)計、新吳網(wǎng)站維護(hù)等服務(wù)，公司將堅持客戶導(dǎo)向、應(yīng)用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長，共同發(fā)展。

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

1）解耦

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

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

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

2）異步

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

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

3）消峰

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

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

也就是說消息隊列每秒鐘 5k 個請求進(jìn)來，1k 個請求出去，假設(shè)高峰期 1 個小時，那么這段時間就可能有幾十萬甚至幾百萬的請求積壓在消息隊列中。不過這個短暫的高峰期積壓是完全可以的，因為高峰期過了之后，每秒鐘就沒有那么多的請求進(jìn)入消息隊列了，但是數(shù)據(jù)庫依然會按照每秒 1k 個請求的速度處理。所以只要高峰期一過，系統(tǒng)就會快速的將積壓的消息給處理掉。

關(guān)于“數(shù)據(jù)庫為什么要用消息隊列”這篇文章的內(nèi)容就介紹到這里，感謝各位的閱讀！相信大家對“數(shù)據(jù)庫為什么要用消息隊列”知識都有一定的了解，大家如果還想學(xué)習(xí)更多知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。