【Java進階面試系列之二】：哥們，那你說說系統架構引入消息中間件有什麼缺點？

歡迎關注我的公衆號：石杉的架構筆記（ID:shishan100）

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

1、前情回顧

上篇文章「Java進階面試系列之一」大家系統架構中爲什麼要引入消息中間件？，給你們講了講消息中間件引入系統架構的做用，主要是解決哪些問題的。

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

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

2、正式開始

這篇文章給你們講講，若是你在系統架構裏引入了消息中間件以後，會有哪些缺點？

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%高可用？

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

3、總結

最後，咱們來作一個簡單的小結。

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

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

END

若有收穫，請幫忙轉發，您的鼓勵是做者最大的動力，謝謝！

一大波微服務、分佈式、高併發、高可用的原創系列文章正在路上

歡迎掃描下方二維碼，持續關注：

石杉的架構筆記（id:shishan100）

十餘年BAT架構經驗傾囊相授

推薦閱讀：

一、拜託！面試請不要再問我Spring Cloud底層原理

二、【雙11狂歡的背後】微服務註冊中心如何承載大型系統的千萬級訪問？

三、【性能優化之道】每秒上萬併發下的Spring Cloud參數優化實戰

四、微服務架構如何保障雙11狂歡下的99.99%高可用

五、兄弟，用大白話告訴你小白都能聽懂的Hadoop架構原理

六、大規模集羣下Hadoop NameNode如何承載每秒上千次的高併發訪問

七、【性能優化的祕密】Hadoop如何將TB級大文件的上傳性能優化上百倍

八、拜託，面試請不要再問我TCC分佈式事務的實現原理坑爹呀！

九、【坑爹呀！】最終一致性分佈式事務如何保障實際生產中99.99%高可用？

十、拜託，面試請不要再問我Redis分佈式鎖的實現原理！

十一、【眼前一亮！】看Hadoop底層算法如何優雅的將大規模集羣性能提高10倍以上？

十二、億級流量系統架構之如何支撐百億級數據的存儲與計算

1三、億級流量系統架構之如何設計高容錯分佈式計算系統

1四、億級流量系統架構之如何設計承載百億流量的高性能架構

1五、億級流量系統架構之如何設計每秒十萬查詢的高併發架構

1六、億級流量系統架構之如何設計全鏈路99.99%高可用架構

1七、七張圖完全講清楚ZooKeeper分佈式鎖的實現原理

1八、大白話聊聊Java併發面試問題之volatile究竟是什麼？

1九、大白話聊聊Java併發面試問題之Java 8如何優化CAS性能？

20、大白話聊聊Java併發面試問題之談談你對AQS的理解？

2一、大白話聊聊Java併發面試問題之公平鎖與非公平鎖是啥？

2二、大白話聊聊Java併發面試問題之微服務註冊中心的讀寫鎖優化

2三、互聯網公司的面試官是如何360°無死角考察候選人的？（上篇）

2四、互聯網公司面試官是如何360°無死角考察候選人的？（下篇）

2五、Java進階面試系列之一：哥們，大家的系統架構中爲何要引入消息中間件？