歡迎關注個人公眾號：石杉的架構筆記（ID:shishan100）

週一至週五早8點半！精品技術文章準時送上！

一、前情回顧

上篇文章「Java進階面試系列之一」你們系統架構中為何要引入訊息中介軟體？，給大家講了講訊息中介軟體引入系統架構的作用，主要是解決哪些問題的。

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

• 複雜系統的解耦
• 複雜鏈路的非同步呼叫
• 瞬時高峰的削峰處理

二、正式開始

這篇文章給大家講講，如果你在系統架構裡引入了訊息中介軟體之後，會有哪些缺點？

1）系統可用性降低

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

比如說一個核心鏈路裡面，系統A -> 系統B -> 系統C，然後系統C是通過MQ非同步呼叫系統D的。

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

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

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

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

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

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

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

• 最終一致性分散式事務如何保障實際生產中99.99%高可用？
• 億級流量系統架構之如何設計全鏈路99.99%高可用架構

通過這兩篇文章，具體看看我們在各種場景下遇到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失敗了，會導致系統整體資料不一致了啊。

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

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

最終一致性分散式事務如何保障實際生產中99.99%高可用？

我們在裡面詳細闡述了系統之間非同步呼叫場景下，如何採用分散式事務方案保證其資料一致性。

三、總結

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

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

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

END