在了解中間件之前，我們先了解一下什么是同步？
首先我們想一下，兩個公司之間如果有互相調用接口的業務需求，如果沒有引入中間件技術，是怎么實現的呢？
用戶發起請求給系統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的精髓之處。
