一定要用訊息隊列？聊聊為什麼要用它

這篇文章為大家帶來了關於訊息隊列的相關知識，其中主要介紹了咱們之所以要使用訊息隊列的原因，為什麼要使用訊息隊列，感興趣的朋友，下面一起來看一下吧，希望對大家有幫助。

為什麼要使用訊息佇列，六個字總結：解耦、非同步、消峰

1）解耦

傳統模式下系統間的耦合性太強。怎麼說呢，舉個例子：系統A 透過介面呼叫發送資料到B、C、D 三個系統，如果將來E 系統存取或B 系統不需要存取了，那麼系統A 還需要修改程式碼，非常麻煩。

如果系統A 產生了一個比較關鍵的數據，那麼它就要時時刻刻考慮B、C、D、E 四個系統如果掛了該咋辦？這條數據它們是否都收到了？顯然，系統 A 跟其它系統嚴重耦合。

而如果我們將資料（訊息）寫入訊息佇列，需要訊息的系統直接自己從訊息佇列中消費。這樣下來，系統 A 就不需要去考慮要給誰發送數據，不需要去維護這個代碼，也不需要考慮其他系統是否調用成功、失敗超時等情況，反正我只負責生產，別的我不管。

2）非同步

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

如果使用訊息佇列，那麼系統A 就只需要發送3 個訊息到訊息佇列就行了，假如耗時5ms，A 系統從接受一個請求到回傳回應給用戶，總時長是1 5 = 6ms，對於用戶而言，體驗好感度直接拉滿。

3）消峰

如果沒有使用快取或訊息佇列，那麼系統就是直接基於資料庫MySQL 的，如果有那麼一個高峰期，產生了大量的請求湧入MySQL，毫無疑問，系統將會直接崩潰。

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

也就是說訊息佇列每秒鐘5k 個請求進來，1k 個請求出去，假設高峰期1 個小時，那麼這段時間就可能有幾十萬甚至幾百萬的請求積壓在訊息隊列中。不過這個短暫的高峰期積壓是完全可以的，因為高峰期過了之後，每秒鐘就沒有那麼多的請求進入訊息佇列了，但是資料庫依然會按照每秒 1k 個請求的速度處理。所以只要高峰期一過，系統就會快速的將積壓的訊息給處理掉。

推薦學習：《Redis影片教學》

以上是一定要用訊息隊列？聊聊為什麼要用它的詳細內容。更多資訊請關注PHP中文網其他相關文章！