一、 前情回顧

上篇文章《??為什么要使用MQ消息中間件?這幾個問題必須拿下!??》，給大家講了講消息中間件引入系統架構的作用，主要是解決哪些問題的。

其比較常見的實踐場景是：

• 復雜系統的解耦
• 復雜鏈路的異步調用
• 瞬時高峰的削峰處理

二、 正式開始

這篇文章給大家講講，如果你在系統架構里引入了消息中間件之后，會有哪些缺點？

1.系統可用性降低

首先是你的系統整體可用性絕對會降低，給你舉個例子，我們就拿之前的一幅圖來說明。

比如說一個核心鏈路里面，系統A -> 系統B -> 系統C，然后系統C是通過MQ異步調用系統D的。

看起來很好，你用這個MQ異步化的手段解決了一個核心鏈路執行性能過差的問題。

但是你有沒有考慮另外一個問題，就是萬一你依賴的那個MQ中間件突然掛掉了怎么辦？這個還真的不是異想天開，MQ、Redis、MySQL這些組件都有可能會掛掉。

一旦你的MQ掛了，就導致你的系統的核心業務流程中斷了。本來你要是不引入MQ中間件，那其實就是一些系統之間的調用，但是現在你引入了MQ，就導致你多了一個依賴。一旦多了一個依賴，就會導致你的可用性降低。

因此，一旦引入了MQ中間件，你就必須去考慮這個MQ是如何部署的，如何保證高可用性。

甚至在復雜的高可用的場景下，你還要考慮如果MQ一旦掛了以后，你的系統有沒有備用兜底的技術方案，可以保證系統繼續運行下去。

之前寫過一篇文章，涉及到了MQ掛掉之后的高可用保障方案。

大伙如果感興趣，可以參考一下：

《??用RocketMQ實現可靠消息最終一致性方案，yyds！??》

通過這篇文章，具體看看我們在各種場景下遇到MQ故障采取的高可用降級方案。

2.系統穩定性降低

還是上面那張圖，大家再來看一下。

不知道大家有沒有發現一個問題，這個鏈路除了MQ中間件掛掉這個可能存在的隱患之外，可能還有一些其他的技術問題。

比如說，莫名其妙的，系統C發了一個消息到MQ，結果那個消息因為網絡故障等問題，就丟失了。這就導致系統D沒有收到那條消息。

這可就慘了，這樣會導致系統D沒完成自己該做的任務，此時可能整個系統會出現業務錯亂，數據丟失，嚴重的bug，用戶體驗很差等各種問題。

這還只是其中之一，萬一說系統C給MQ發送消息，不小心一抽風重復發了一條一模一樣的，導致消息重復了，這個時候該怎么辦？

可能會導致系統D一下子把一條數據插入了兩次，導致數據錯誤，臟數據的產生，最后一樣會導致各種問題。

或者說如果系統D突然宕機了幾個小時，導致無法消費消息，結果大量的消息在MQ中間件里積壓了很久，這個時候怎么辦？

即使系統D恢復了，也需要慢慢的消費數據來進行處理。

所以這就是引入MQ中間件的第二個大問題，系統穩定性可能會下降，故障會增多，各種各樣亂七八糟的問題都可能產生。

而且一旦產生了一個問題，就會導致系統整體出問題。就需要為了解決各種MQ引發的技術問題，采取很多的技術方案。

關于這個，我們后面會用專門的文章聊聊MQ中間件的這些問題的解決方案，包括：

• 消息高可靠傳遞（0丟失）
• 消息冪等性傳遞（絕對不重復）
• 百萬消息積壓的線上故障處理

3.分布式一致性問題

引入消息中間件，還有分布式一致性的問題。

舉個例子，比如說系統C現在處理自己本地數據庫成功了，然后發送了一個消息給MQ，系統D也確實是消費到了。

但是結果不幸的是，系統D操作自己本地數據庫失敗了，那這個時候咋辦？

系統C成功了，系統D失敗了，會導致系統整體數據不一致了啊。

所以此時又需要使用可靠消息最終一致性的分布式事務方案來保障。

關于這個，可以參考之前的一篇文章：

《??用RocketMQ實現可靠消息最終一致性方案，yyds！??》

我們在里面詳細闡述了系統之間異步調用場景下，如何采用分布式事務方案保證其數據一致性。

三、總結

最后，我們來做一個簡單的小結。

在面試中要答好這個問題，首先一定要熟悉MQ這個技術的優缺點。了解清楚把他引入系統是為了解決哪些問題的，但是他自身又會帶來哪些問題。

此外，對于引入MQ以后，是否對他自身可能引發的問題有一些方案的設計，來保證你的系統高可用、高可靠的運行，保證數據的一致性。這個也有做好相應的準備。?