1. MQ的產生背景

微服務架構后，鏈式調用是我們在寫程序時候的一般流程,為了完成一個整體功能會將其拆分成多個函數(或子模塊)，比如模塊A調用模塊B,模塊B調用模塊C,模塊C調用模塊D。但在大型分布式應用中，系統間的RPC交互繁雜，一個功能背后要調用上百個接口并非不可能，從單機架構過渡到分布式微服務架構的通例。這些架構會有哪些問題？

(1)系統之間接口耦合比較嚴重

每新增一個下游功能，都要對上游的相關接口進行改造；

舉個例子：如果系統A要發送數據給系統B和系統C，發送給每個系統的數據可能有差異，因此系統A對要發送給每個系統的數據進行了組裝，然后逐一發送；

當代碼上線后又新增了一個需求：把數據也發送給D，新上了一個D系統也要接受A系統的數據，此時就需要修改A系統，讓他感知到D系統的存在，同時把數據處理好再給D。在這個過程你會看到，每接入一個下游系統，都要對系統A進行代碼改造，開發聯調的效率很低。其整體架構如下圖：

(2)面對大流量并發時，容易被沖垮

每個接口模塊的吞吐能力是有限的，這個上限能力如果是堤壩，當大流量（洪水）來臨時，容易被沖垮。

舉個例子秒殺業務：上游系統發起下單購買操作，就是下單一個操作，很快就完成。然而，下游系統要完成秒殺業務后面的所有邏輯（讀取訂單，庫存檢查，庫存凍結，余額檢查，余額凍結，訂單生產，余額扣減，庫存減少，生成流水，余額解凍，庫存解凍）

(3)等待同步存在性能問題

RPC接口上基本都是同步調用，整體的服務性能遵循“木桶理論”，即整體系統的耗時取決于鏈路中最慢的那個接口。比如A調用B/C/D都是50ms，但此時B又調用了B1，花費2000ms，那么直接就拖累了整個服務性能。

根據上述的幾個問題，在設計系統時可以明確要達到的目標：

1，要做到系統解耦，當新的模塊接進來時，可以做到代碼改動最小；能夠解耦

2，設置流量緩沖池，可以讓后端系統按照自身吞吐能力進行消費，不被沖垮；能削峰

3，強弱依賴梳理能將非關鍵調用鏈路的操作異步化并提升整體系統的吞吐能力；能夠異步

2. MQ的主要作用

(1)異步。調用者無需等待。

(2)解耦。解決了系統之間耦合調用的問題。

(3)消峰。抵御洪峰流量，保護了主業務

3. MQ的定義

面向消息的中間件（message-oriented middleware）MOM能夠很好的解決以上問題。是指利用高效可靠的消息傳遞機制與平臺無關的數據交流，并基于數據通信來進行分布式系統的集成。通過提供消息傳遞和消息排隊模型在分布式環境下提供應用解耦，彈性伸縮，冗余存儲、流量削峰，異步通信，數據同步等功能。

大致的過程是這樣的：發送者把消息發送給消息服務器，消息服務器將消息存放在若干隊列/主題topic中，在合適的時候，消息服務器回將消息轉發給接受者。在這個過程中，發送和接收是異步的，也就是發送無需等待，而且發送者和接受者的生命周期也沒有必然的關系；尤其在發布pub/訂閱sub模式下，也可以完成一對多的通信，即讓一個消息有多個接受者。

4. MQ的特點

(1)采用異步處理模式

消息發送者可以發送一個消息而無須等待響應。消息發送者將消息發送到一條虛擬的通道（主題或者隊列）上；

消息接收者則訂閱或者監聽該愛通道。一條消息可能最終轉發給一個或者多個消息接收者，這些消息接收者都無需對消息發送者做出同步回應。整個過程都是異步的。

案例：

也就是說，一個系統跟另一個系統之間進行通信的時候，假如系統A希望發送一個消息給系統B，讓他去處理。但是系統A不關注系統B到底怎么處理或者有沒有處理好，所以系統A把消息發送給MQ，然后就不管這條消息的“死活了”，接著系統B從MQ里面消費出來處理即可。至于怎么處理，是否處理完畢，什么時候處理，都是系統B的事兒，與系統A無關。

(2)應用系統之間解耦合

發送者和接受者不必了解對方，只需要確認消息。

發送者和接受者不必同時在線。

(3)整體架構

以上就是對“ActiveMQ視頻下載，基礎入門”的介紹，希望對大家有所幫助，還想學習更多關于Java的課程，可以關注動力節點官網Java視頻教程，免費下載學習。