一、系統中爲什麼需要用到消息隊列，使用消息隊列有什麼優點？
使用消息隊列的優點很多，這裏就說比較重要的三個優點：解耦、異步、削峯填谷。
①、解耦：
首先引入一個場景：系統A作位一個接口請求方，現在需要向B、C、D三個系統發送請求，這個時候呢A系統不需要發送請求給D系統了，而需要發送請求給E系統，那麼在A系統裏面就需要修改代碼，每一次發送的請求方改變的話，都需要改代碼，具有一定的耦合性。如下圖：
那麼我們引入消息隊列之後呢，A系統把需要發送的請求數據放到隊列裏即可，不需要關心哪個系統需要A系統的請求數據，如下圖所示：
②、異步：
在引入一個場景：用戶請求A系統，然後A系統還需同步調用B、C、D系統的接口，我們假設一下再A系統處理自身業務邏輯請求了一個sql的時間是200ms,然後調用B系統等待B系統處理幾個sql的時間是300ms,在調用C系統處理業務邏輯200ms，在調用D系統處理業務邏輯200ms,那麼一次請求至少等待1秒纔會響應。比較耗時，如下圖所示：
那麼我們再引入消息隊列之後，用戶調用A系統花費了200ms，然後A系統發送三條消息到消息隊列裏面去，總耗時是5ms左右，然後B、C、D系統去消費就行了，總共只花費200ms左右，如下圖所示：
③、削峯填谷
當大量的用戶（100萬）通過瀏覽器再中午高峯期，同時進行大量的操作，會給數據庫造成極大的壓力，可能導致mysql宕機，如圖所示：
但是中午高峯期過了的話，下午可能也就1萬左右的用戶在操作了，每秒50個請求左右，對系統沒有任何壓力，如果高峯期時將5000個請求寫到MQ裏面的話，系統A最多每秒執行2000個請求，不要超過每秒做大請求數就行，經過了2個小時的中午高峯期，再慢慢消費隊列裏面的消息，這個是可以接受的。如下圖所示：
二、使用消息隊列有什麼缺點
上面說了引入消息隊列的一些場景和優點，那麼使用消息隊列有什麼缺點呢？
系統的可用性降低：比如第一個例子，本來好好的調用三個接口，這個時候接入一個消息隊列，湊巧消息隊列掛掉了，系統不是直接不能用了，崩潰掉了。
系統的複雜性：加入一個消息隊列，若是消息丟失怎麼辦，消息被重複消費了，消息沒有按找既定的順序消費，都會導致系統出問題。
一致性問題：A系統處理完了直接返回成功了，那麼用戶就以爲成功了，實際上，BC消費成功了，D消費失敗了，數據就不一致了。
所以使用消息隊列會使系統的複雜程度增加一個級別，但是需要用的時候還是得用，做好綜合考量。