什麼是消息中間件？主要作用是什麼？
在了解中間件之前，我們先了解一下什麼是同步？
首先我們想一下，兩個公司之間如果有互相調用介面的業務需求，如果沒有引入中間件技術，是怎麼實現的呢？
用戶發起請求給系統A，系統A接到請求直接調用系統B，系統B返回結果後，系統A才能返回結果給用戶，這種模式就是同步調用。
所謂同步調用就是各個系統之間互相依賴，一個系統發送請求，其他系統也會跟著依次進行處理，只有所有系統處理完成後對於用戶來講才算完成了一次請求。只要其他系統出現故障，就會報錯給用戶。
那麼引入中間件後，是如何做到非同步調用的呢？
用戶發起請求給系統A，此時系統A發送消息給MQ，然後就返回結果給用戶，不去管系統B了。然後系統B根據自己的情況，去MQ中獲取消息，獲取到消息的時候可能已經過了1分鐘甚至1小時，再根據消息的指示執行相應的操作。
那麼想一想，系統A和系統B互相之間是否有通訊？這種調用方式是同步調用嗎？
系統A發送消息給中間件後，自己的工作已經完成了，不用再去管系統B什麼時候完成操作。而系統B拉去消息後，執行自己的操作也不用告訴系統A執行結果，所以整個的通訊過程是非同步調用的。
說到這裡，我們可以做個總結，消息中間件到底是什麼呢？
其實消息中間件就是一個獨立部署的系統。可以實現各個系統之間的非同步調用。當然它的作用可不止這些，通過它可以解決大量的技術痛點，我們接下來會進行介紹。
消息中間件，總結起來作用有三個：非同步化提升性能、降低耦合度、流量削峰。
非同步化提升性能
先來說說非同步化提升性能，上邊我們介紹中間件的時候已經解釋了引入中間件後，是如何實現非同步化的，但沒有解釋具體性能是怎麼提升的，我們來看一下下邊的圖。
沒有引入中間件的時候，用戶發起請求到系統A，系統A耗時20ms，接下來系統A調用系統B，系統B耗時200ms，帶給用戶的體驗就是，一個操作全部結束一共耗時220ms。
如果引入中間件之後呢？看下邊的圖。
用戶發起請求到系統A，系統A耗時20ms，發送消息到MQ耗時5ms，返回結果一共用了25ms，用戶體驗一個操作只用了25ms，而不用管系統B什麼時候去獲取消息執行對應操作，這樣比較下來，性能自然大大提高
降低耦合度
再來聊聊解耦的場景，看下圖。
如果沒有引入中間件，那麼系統A調用系統B的時候，系統B出現故障，導致調用失敗，那麼系統A就會接到異常資訊，接到異常資訊後肯定要再處理一下，返回給用戶失敗請稍後再試，這時候就得等待系統B的工程師解決問題，一切都解決好後再告知用戶可以了，再重新操作一次吧。
這樣的架構，兩個系統耦合再一起，用戶體驗極差。
那麼我們引入中間件後是什麼樣的場景呢，看下面的流程：
對於系統A，發送消息後直接返回結果，不再管系統B後邊怎麼操作。而系統B故障恢復後重新到MQ中拉取消息，重新執行未完成的操作，這樣一個流程，系統之間沒有影響，也就實現了解耦。
流量削峰
下面我們再聊聊最後一個場景，流量削峰
假如我們的系統A是一個集群，不連接資料庫，這個集群本身可以抗下1萬QPS
系統B操作的是資料庫，這個資料庫只能抗下6000QPS，這就導致無論系統B如何擴容集群，都只能抗下6000QPS，它的瓶頸在於資料庫。
假如突然系統QPS達到1萬，就會直接導致資料庫崩潰，那麼引入MQ後是怎麼解決的呢，見下圖：
引入MQ後，對於系統A沒有什麼影響，給MQ發送消息可以直接發送1萬QPS。
此時對於系統B，可以自己控制獲取消息的速度，保持在6000QPS一下，以一個資料庫能夠承受的速度執行操作。這樣就可以保證資料庫不會被壓垮。
當然，這種情況MQ中可能會積壓大量消息。但對於MQ來說，是允許消息積壓的，等到系統A峰值過去，恢復成1000QPS時，系統B還是在以6000QPS的速度去拉取消息，自然MQ中的消息就慢慢被釋放掉了。
這就是流量削峰的過程。在電商秒殺、搶票等等具有流量峰值的場景下可以使用這麼一套架構。
好了，本文對MQ的講解就到這裡，本系列中間件專題將會逐步深入，帶你體驗MQ的精髓之處。
歡迎關注公眾號HUC思夢，不定時分享一個IT愛好者的學習、生活與見聞。
掃碼關注後，回復「面試」領取java工程師實用面試資料！並不定時有免費資源分享！
