一 前情回顧

上篇文章??《做了幾年開發(fā)，你知道自己的系統(tǒng)為什么要用消息中間件嗎？》??，給大家講了講消息中間件引入系統(tǒng)架構(gòu)的作用，主要是解決哪些問題的。

其比較常見的實(shí)踐場景是：

• 復(fù)雜系統(tǒng)的解耦
• 復(fù)雜鏈路的異步調(diào)用
• 瞬時(shí)高峰的削峰處理

二、正式開始

這篇文章給大家講講，如果你在系統(tǒng)架構(gòu)里引入了消息中間件之后，會有哪些缺點(diǎn)？

1、系統(tǒng)可用性降低

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

比如說一個(gè)核心鏈路里面，系統(tǒng)A -> 系統(tǒng)B -> 系統(tǒng)C，然后系統(tǒng)C是通過MQ異步調(diào)用系統(tǒng)D的。

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

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

一旦你的MQ掛了，就導(dǎo)致你的系統(tǒng)的核心業(yè)務(wù)流程中斷了。本來你要是不引入MQ中間件，那其實(shí)就是一些系統(tǒng)之間的調(diào)用，但是現(xiàn)在你引入了MQ，就導(dǎo)致你多了一個(gè)依賴。一旦多了一個(gè)依賴，就會導(dǎo)致你的可用性降低。

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

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

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

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

2、系統(tǒng)穩(wěn)定性降低

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

不知道大家有沒有發(fā)現(xiàn)一個(gè)問題，這個(gè)鏈路除了MQ中間件掛掉這個(gè)可能存在的隱患之外，可能還有一些其他的技術(shù)問題。

比如說，莫名其妙的，系統(tǒng)C發(fā)了一個(gè)消息到MQ，結(jié)果那個(gè)消息因?yàn)榫W(wǎng)絡(luò)故障等問題，就丟失了。這就導(dǎo)致系統(tǒng)D沒有收到那條消息。

這可就慘了，這樣會導(dǎo)致系統(tǒng)D沒完成自己該做的任務(wù)，此時(shí)可能整個(gè)系統(tǒng)會出現(xiàn)業(yè)務(wù)錯(cuò)亂，數(shù)據(jù)丟失，嚴(yán)重的bug，用戶體驗(yàn)很差等各種問題。

?這還只是其中之一，萬一說系統(tǒng)C給MQ發(fā)送消息，不小心一抽風(fēng)重復(fù)發(fā)了一條一模一樣的，導(dǎo)致消息重復(fù)了，這個(gè)時(shí)候該怎么辦？

可能會導(dǎo)致系統(tǒng)D一下子把一條數(shù)據(jù)插入了兩次，導(dǎo)致數(shù)據(jù)錯(cuò)誤，臟數(shù)據(jù)的產(chǎn)生，最后一樣會導(dǎo)致各種問題。

或者說如果系統(tǒng)D突然宕機(jī)了幾個(gè)小時(shí)，導(dǎo)致無法消費(fèi)消息，結(jié)果大量的消息在MQ中間件里積壓了很久，這個(gè)時(shí)候怎么辦？

即使系統(tǒng)D恢復(fù)了，也需要慢慢的消費(fèi)數(shù)據(jù)來進(jìn)行處理。

所以這就是引入MQ中間件的第二個(gè)大問題，系統(tǒng)穩(wěn)定性可能會下降，故障會增多，各種各樣亂七八糟的問題都可能產(chǎn)生。

而且一旦產(chǎn)生了一個(gè)問題，就會導(dǎo)致系統(tǒng)整體出問題。就需要為了解決各種MQ引發(fā)的技術(shù)問題，采取很多的技術(shù)方案。

關(guān)于這個(gè)，我們后面會用專門的文章聊聊MQ中間件的這些問題的解決方案，包括：?

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

3、分布式一致性問題

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

舉個(gè)例子，比如說系統(tǒng)C現(xiàn)在處理自己本地?cái)?shù)據(jù)庫成功了，然后發(fā)送了一個(gè)消息給MQ，系統(tǒng)D也確實(shí)是消費(fèi)到了。

但是結(jié)果不幸的是，系統(tǒng)D操作自己本地?cái)?shù)據(jù)庫失敗了，那這個(gè)時(shí)候咋辦？

系統(tǒng)C成功了，系統(tǒng)D失敗了，會導(dǎo)致系統(tǒng)整體數(shù)據(jù)不一致了啊。

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

我們在里面詳細(xì)闡述了系統(tǒng)之間異步調(diào)用場景下，如何采用分布式事務(wù)方案保證其數(shù)據(jù)一致性。

三 總結(jié)

最后，我們來做一個(gè)簡單的小結(jié)。

在面試中要答好這個(gè)問題，首先一定要熟悉MQ這個(gè)技術(shù)的優(yōu)缺點(diǎn)。了解清楚把他引入系統(tǒng)是為了解決哪些問題的，但是他自身又會帶來哪些問題。

此外，對于引入MQ以后，是否對他自身可能引發(fā)的問題有一些方案的設(shè)計(jì)，來保證你的系統(tǒng)高可用、高可靠的運(yùn)行，保證數(shù)據(jù)的一致性。這個(gè)也有做好相應(yīng)的準(zhǔn)備。