“在本文的開頭，我們將討論消息中間件的高頻訪問問題，它也將涵蓋MQ中間件的一些常見技術問題。如果面試官看了你的簡歷中使用MQ中間件的經歷，可能會有以下問題：在你的公司的生產環境中使用了什麼消息中間件？爲什麼要將消息中間件引入系統？引入消息中間件的優點和缺點是什麼？好，讓我們逐一分析。
一、你們公司生產環境用的是什麼消息中間件？
首先，您可以說您的公司選擇了哪種消息中間件，比如Rabbit MQ，然後可以對您選擇的不同MQ中間件技術進行一些初步分析。例如：ActiveMQ是一個老式的新聞中間件。在中國，許多公司曾經廣泛使用過它，並且擁有強大的功能。但問題在於，ActiveMQ不能支持Internet公司高併發性、高負載和高吞吐量的複雜場景，而且中國的Internet公司數量較少。此外，一些傳統企業使用ActiveMQ進行異步調用和系統解耦。然後您可以說RabbitMQ，它具有支持高併發性、高吞吐量、高性能以及非常完美和方便的後臺管理接口的優點。此外，他還支持集羣、高可用性部署架構、高可靠消息支持和更好的功能。
此外，經過調查，大型RabbitMQ集羣支持自身業務的案例更多，國內各種中小型互聯網公司使用RabbitMQ的做法也更多。此外，RabbitMQ的開放源碼社區非常活躍，通過頻繁的迭代來修復發現的bug並對其進行優化，所以經過全面考慮，公司採用了RabbitMQ。但是RabbitMQ也有一些缺點，即它基於Erlang語言開發，因此更難分析內部源代碼，更難對源代碼進行深入定製和改造。畢竟，它需要更堅實的Erlang語言基礎。然後我們可以討論一下RocketMQ，它是Ali的開放源代碼。它已經通過了Ali生產環境中高併發性和高吞吐量的測試。它還支持特殊的場景，如分佈式事務。基於Java語言開發了RoCKMQ。它適合於源代碼的深入閱讀。有必要在源代碼級別解決在線生產問題，包括二次開發和修改源代碼。另一個是卡夫卡。Kafka的消息中間件特性明顯小於上面提到的MQ中間件的特性。但是Kafka的優點是它被設計用於超高吞吐量的實時日誌採集、實時數據同步、實時數據計算和其他場景。因此，卡夫卡被廣泛應用於具有實時計算技術的大數據領域（如火花流、風暴、Fl.）。但它很少用於傳統的MQ中間件使用場景。PS：如果您還沒有在自己的計算機上部署上述MQ技術，並且沒有編寫一些HelloWorld經驗，那麼建議您首先到每種技術的官方網站上查找HelloWorld演示，並自己運行和播放。
二、爲什麼在你們系統架構中要引入消息中間件？
要回答這個問題，您應該首先討論消息傳遞中間件的常見使用場景。
然後，根據您自己的系統的相應使用場景，我將討論通過將消息中間件引入到您的系統中解決了哪些問題。
1）系統解耦
假設您有一個系統A，它產生核心數據，現在下游系統B和C需要該數據。
很簡單。系統A只調用系統B和系統C的接口直接向它們發送數據。
整個過程，如下圖所示。
但如果我們談到系統D、系統E、系統F、系統G等等，那麼其他十幾個系統會慢慢需要這些核心數據嗎？如下圖所示。
別以爲這是開玩笑。一個大型系統通常被劃分爲幾十個甚至數百個子系統。每個子系統對應多個服務。這些系統和系統之間存在着複雜的關係。
如果系統產生核心數據，那麼無數其他下游系統可能需要它來實現各種業務邏輯。
此時，如果您採用上述模式來設計系統體系結構，那麼負責系統A的學生絕對會厭煩至死。
首先，有人來要求他向一個新系統H發送數據。系統A的學生必須修改代碼，然後在代碼中添加調用新系統H的過程。
稍後，舊的系統B將脫機，告訴系統A的學生：不要給我數據，然後系統A將再次修改代碼，並停止給系統B。
那麼，如果下游系統突然出現故障怎麼辦？系統A的調用代碼中是否引發異常？系統A的學生收到警報說系統不正常，他不得不去注意哪個下游系統出故障了。
因此，在實際的系統架構設計中，如果都採用這種系統耦合方式，在某些情況下是絕對不合適的，並且系統耦合程度太嚴重。
而耦合不是核心鏈路的呼喚，而是一些非核心場景（如數據消耗）導致系統耦合，這將嚴重影響上下游系統開發和維護的效率。
因此，在上述系統架構中，MQ中間件可以實現系統解耦。
系統A將其核心數據之一發送給MQ，MQ的下游系統希望自己使用它，並且不需要就取消對數據的消耗，如下圖所示。
2）異步調用
假設您有一個系統調用鏈接，系統A調用系統B，通常需要20ms；系統B調用系統C，通常需要200ms；系統C調用系統D，通常需要2秒，如下圖所示。
現在最大的問題是用戶的請求來得很慢，因爲完成一個鏈接需要20ms+200ms+2000ms(2s)=2220ms，或者超過2秒。
但實際上，系統A在鏈路呼叫系統B和系統B呼叫系統C，這兩個步驟加起來是220M。
由於引入了系統C調用系統D步驟，最終的鏈路執行時間超過2秒，這直接將鏈路調用性能降低了10倍，這是鏈路執行緩慢的罪魁禍首。
此時，我們可以考慮是否可以將系統D從鏈接中拉出來進行異步調用。事實上，許多業務場景都允許異步調用。
例如，當您訂購外賣時，單擊訂單並支付，賬戶扣除錢，創建訂單，並通知商家爲您準備菜。
接下來，你需要騎車送餐嗎？然後，尋找騎手的過程需要一個複雜的算法來實現調度，這非常耗時。
但事實上，在幾十秒後完成騎手的調度是可以的，因爲當你付錢的時候，它並不真的需要找到一個好的騎手，也不是必須的。
因此，我們能否採取步驟找到一個騎手送餐給您脫離鏈接，並使其異步，即使它被延遲了數十秒，但只要我們找到一個騎手送餐給您在一定的時間範圍？
這是否允許您更快地在外賣點下訂單？一旦付款成功，可以創建訂單，扣除帳戶，並通知商家立即爲您準備菜餚。這個過程可能需要數百毫秒。
然後，後臺異步可能需要幾十秒才能找到騎手通過調度算法遞送餐點，但是這個步驟不會快速影響我們的訂購。
當然，我們不是說那些熟悉的外賣平臺的技術框架必須以這種方式實現，而是使用生活中的一個常見示例來說明它。
所以上面的鏈接是一樣的。如果業務流程支持異步，我們能否考慮將系統C對系統D的調用撤出以進行異步，而不是依次在鏈接中對調用進行同步？
以這種方式，實現的思想是系統A->系統B->系統C，它直接消耗220ms並獲得成功。
然後，系統C向MQ中間件發送消息，MQ中間件被系統D使用，並緩慢異步以執行消耗2s的業務流程。這樣，核心鏈路的性能直接提高了10倍。
整個過程，如下圖所示。
3）流量削峯
假設你有一個系統，平時正常的時候每秒可能就幾百個請求，系統部署在8核16G的機器的上，正常處理都是ok的，每秒幾百請求是可以輕鬆抗住的。
但是如下圖所示，在高峯期一下子來了每秒鐘幾千請求，瞬時出現了流量高峯，此時你的選擇是要搞10臺機器，抗住每秒幾千請求的瞬時高峯嗎？
如果瞬時峯值每天只有半小時，那麼它直接減少到每秒數百個請求。如果在線部署許多機器，那麼每臺機器每秒可以處理幾十個請求。那不是浪費機器資源嗎？
大多數情況下，每秒數百個請求，一臺機器就足夠了，但是爲了抵禦每天的瞬時峯值，部署了10臺機器，每天使用半小時，並且在其他時間浪費資源。
但是，如果部署一臺機器，它會導致一個瞬間的高峯時間，這會淹沒您的系統，因爲絕對沒有辦法每秒承受數千個請求。
此時，我們可以使用MQ中間件來降低流量峯值。所有機器前面都裝有一層MQ。通常每秒可以容易地接收數百個請求。
一旦達到瞬時峯值，每秒可以備份數千個請求，然後機器緩慢地處理和消耗。
當高峯期結束並且消耗持續時間稍長時，將消耗MQ中的積壓數據。
這是MQ的典型應用，它使用有限的機器資源承載高併發請求。如果業務場景允許異步調峯，則高峯期在MQ中積壓一些請求，然後高峯期結束，並且後端系統在一定時間段之後不再積壓，那麼使用這種技術方案是非常合適的。