一文看懂消息中間件

在瞭解中間件以前，咱們先了解一下什麼是同步？

首先咱們想一下，兩個公司之間若是有互相調用接口的業務需求，若是沒有引入中間件技術，是怎麼實現的呢？

用戶發起請求給系統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中的消息就慢慢被釋放掉了。

這就是流量削峯的過程。在電商秒殺、搶票等等具備流量峯值的場景下可使用這麼一套架構。

最後

感謝你們看到這裏，文章有不足，歡迎你們指出；若是你以爲寫得不錯，那就給我一個贊吧。