消息隊列最常的使用場景：解耦，異步，削峯。
1.解耦：
比如說圖中A系統需要給圖中的BCDE系統發送消息，但是突然有一天有個F系統也想要A給它發消息呢？C有一天不想要A給他發了呢？A還要關心這些系統是不是正常的收到了消息.......每次都要改，急死了！
有沒有辦法解決這個問題呢？這個時候使用如果使用MQ就可以解決這個問題，採用pub/sub發佈訂閱消息模型。如圖：
A 系統產生一條數據，發送到 MQ 裏面去，哪個系統需要數據自己去 MQ 裏面消費。如果新系統需要數據，直接從 MQ 裏消費即可；如果某個系統不需要這條數據了，就取消對 MQ 消息的消費即可。這樣下來，A 系統壓根兒不需要去考慮要給誰發送數據，不需要維護這個代碼，也不需要考慮人家是否調用成功、失敗超時等情況。這樣A系統就跟其他系統進行解耦了。
2.異步
比如說一個用戶請求了一個A系統的某個功能，這個功能需要調用B,C,D系統的某某接口才能完全完成，但是其實有些時候用戶只關心A系統的這個事有沒有完成，而對整個系統功能有沒有完成並不關心（有可能B,C,D這些系統只是一些相關的落庫操作之類的），用戶只會覺得這個怎麼這麼慢啊！這時候同樣可以藉助MQ來解決這個問題。
如果使用MQ，那麼 A 系統連續發送 3 條消息到 MQ 隊列中，假如耗時 5ms，A 系統從接受一個請求到返回響應給用戶，總時長是 3 + 5 = 8ms，對於用戶而言，其實感覺上就是點個按鈕，8ms 以後就直接返回了，爽！網站做得真好，真快！
3.削峯
比如說一天之中晚上幾乎沒有什麼業務，也就沒什麼請求，但是一到早上8點以後，請求就開始多起來了，一般到中午12點達到一個高峯，每秒都有5K-1w的請求量，大量的數據庫寫操作，數據庫需要每秒執行5K-1w的SQL，這個壓力可想而知，於是系統成功的掛了。系統的最大處理能力就只有每秒處理2k請求量的能力，怎麼辦呢？
如果使用 MQ，每秒 5k 個請求寫入 MQ，A 系統每秒鐘最多處理 2k 個請求，因爲 數據庫每秒鐘最多處理 2k 個。A 系統從 MQ 中慢慢拉取請求，每秒鐘就拉取 2k 個請求，不要超過自己每秒能處理的最大請求數量就 ok，這樣下來，哪怕是高峯期的時候，A 系統也絕對不會掛掉。而 MQ 每秒鐘 5k 個請求進來，就 2k 個請求出去，結果就導致在中午高峯期（1 個小時），可能有幾十萬甚至幾百萬的請求積壓在 MQ 中。
這個短暫的高峯期積壓是 ok 的，因爲高峯期過了之後，每秒鐘就 50 個請求進 MQ，但是 A 系統依然會按照每秒 2k 個請求的速度在處理。所以說，只要高峯期一過，A 系統就會快速將積壓的消息給解決掉。
