感謝博主的分享，**：系統架構中為什麼要引入訊息中介軟體？
在本文的開頭，我們將討論訊息中介軟體的高頻訪問問題，它也將涵蓋mq中介軟體的一些常見技術問題。如果面試官看了你的簡歷中使用mq中介軟體的經歷，可能會有以下問題：在你的公司的生產環境中使用了什麼訊息中介軟體？為什麼要將訊息中介軟體引入系統？引入訊息中介軟體的優點和缺點是什麼？好，讓我們逐一分析。
一、你們公司生產環境用的是什麼訊息中介軟體？
首先，您可以說您的公司選擇了哪種訊息中介軟體，比如rabbit mq，然後可以對您選擇的不同mq中介軟體技術進行一些初步分析。例如：activemq是乙個老式的新聞中介軟體。在中國，許多公司曾經廣泛使用過它，並且擁有強大的功能。但問題在於，activemq不能支援internet公司高併發性、高負載和高吞吐量的複雜場景，而且中國的internet公司數量較少。此外，一些傳統企業使用activemq進行非同步呼叫和系統解耦。然後您可以說rabbitmq，它具有支援高併發性、高吞吐量、高效能以及非常完美和方便的後台管理介面的優點。此外，他還支援集群、高可用性部署架構、高可靠訊息支援和更好的功能。
二、為什麼在你們系統架構中要引入訊息中介軟體？
要回答這個問題，您應該首先討論訊息傳遞中介軟體的常見使用場景。
然後，根據您自己的系統的相應使用場景，我將討論通過將訊息中介軟體引入到您的系統中解決了哪些問題。
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臺機器，抗住每秒幾千請求的瞬時高峰嗎？
但是，如果部署一台機器，它會導致乙個瞬間的高峰時間，這會淹沒您的系統，因為絕對沒有辦法每秒承受數千個請求。
此時，我們可以使用mq中介軟體來降低流量峰值。所有機器前面都裝有一層mq。通常每秒可以容易地接收數百個請求。
一旦達到瞬時峰值，每秒可以備份數千個請求，然後機器緩慢地處理和消耗。
當高峰期結束並且消耗持續時間稍長時，將消耗mq中的積壓資料。
這是mq的典型應用，它使用有限的機器資源承載高併發請求。如果業務場景允許非同步調峰，則高峰期在mq中積壓一些請求，然後高峰期結束，並且後端系統在一定時間段之後不再積壓，那麼使用這種技術方案是非常合適的。
為什麼要引入補碼
現在我們知道了計算機可以有三種編碼方式表示乙個數.對於正數因為三種編碼方式的結果都相同,所以不需要過多解釋 原碼 1 0000 0001 反碼 1 0000 0001 補碼 1 0000 0001 為了解決原碼做減法的問題,出現了反碼 1 1 1 1 0000 0001 原 1000 0001 原 ...
為什麼要引入註解
使用annotation之前 甚至在使用之後 xml被廣泛的應用於描述元資料。不知何時開始一些應用開發人員和架構師發現xml的維護越來越糟糕了。他們希望使用一些和 緊耦合的東西，而不是像xml那樣和 是松耦合的 在某些情況下甚至是完全分離的 描述。如果你在google中搜尋 xml vs.annot...
為什麼要引入保護成員
在c 成員中我們需要一種成員比私有成員訪問範圍大比公有成員訪問範圍小的成員。因此就引入了保護成員。保護成員擴大範圍表現在基類的保護成員在派生類的成員函式中被訪問。基類的成員本身就是派生類的成員，但是出於隱藏目的不宜設為公有，但是又確實需要在派生類的成員函式中經常訪問基類成員，將其設定成保護成員，既能...