看看MQ？必須告訴你為什麼要使用MQ訊息中介軟體（圖解版）

mzmp什麼意思

場景一：系統解耦

假設你有個系統A，這個系統A會產出一個核心資料，現在下游有系統B和系統C需要使用這個資料。

首先想到最簡單，系統A就是直接呼叫系統B和系統C的介面傳送資料給他們就好了

但是現在要是來了系統D、系統E、系統F、系統G，等等，十來個其他系統都需要這份核心資料呢？

這是可能會出現開發人員最頭疼的、尷尬的問題？

先是來一個人找他要求傳送資料給一個新的系統H，系統A的同學要修改程式碼然後在那個程式碼里加入呼叫新系統H的流程。

一會那個系統B是個陳舊老系統要下線了，告訴系統A的同學：別給我傳送資料了，接著系統A再次修改程式碼不再給這個系統B。

那我們現在該怎麼做呢？系統的耦合性那麼高，這真是牽一髮而動全身，小需求需要大改動，何必呢？

現在我們主角要來了，可以使用MQ訊息中介軟體，讓我們系統之間耦合度降低。

現在我們只需要將系統A自己的一份核心資料傳送到MQ中介軟體中，下游哪個系統感興趣自己去消費即可。

這樣能達到一次編譯不必改，誰愛誰去改，反正我不改。

總結：透過 MQ 訊息中介軟體的使用，重構系統之間的耦合，讓系統具備高度的可擴充套件性。

場景二：非同步呼叫

假設你有一個系統呼叫鏈路，是系統A呼叫系統B，一般耗時20ms；系統B呼叫系統C，一般耗時200ms；系統C呼叫系統D，一般耗時2s

使用者一個請求過來巨慢無比，就像走過長長的套路一樣

因為走完一個鏈路，需要耗費：

20ms + 200ms + 2000ms（2s） = 2220ms，

也就是2秒多的時間。但是實際上，鏈路中的系統A呼叫系統B，系統B呼叫系統C，這兩個步驟起來也就220ms。

這時候主角大佬又慢慢的過來了，這都搞不定，不是很簡單嗎？

實現思路就是系統A -> 系統B -> 系統C，直接就耗費220ms後直接成功了。

然後系統C就是傳送個訊息到MQ中介軟體裡，由系統D消費到訊息之後慢慢的非同步來執行這個耗時2s的業務處理。透過這種方式直接將核心鏈路的執行效能提升了10倍。

總結：

1）對使用者來說，比同步時更加快捷，使用者體驗非常好。（讓使用者以為自己搶到了，欺騙ing ）

2）對系統訪問壓力來說，非同步因為沒有真正執行，不會造成某時刻對系統的訪問壓力劇增，而是放入佇列，慢慢去消費！

場景三：流量削峰

假設你有一個系統，平時正常的時候每秒可能就幾百個請求，系統部署在8核16G的機器的上，正常處理都是OK的，每秒幾百請求是可以輕鬆抗住的。 比如秒殺活動

在秒殺活動在高峰期一下子來了每秒鐘幾千、萬請求，彈指一揮間出現了流量高峰。

如果時候出現機器宕機，公司損失可是大大的，這是你是不是該準備好被老闆痛罵，甚至可能要

say goodbye

可能想到的解決的方式，線上部署了很多臺機器，一多制勝的方法：

但是，假設除了秒殺活動達到瞬時高峰，其它時間基本為每秒就幾百請求，如果你線上部署了很多臺機器，就是為了這次秒殺活動，這有點浪費機器資源。

所以這時，MQ大哥又出現了，不怕，這不是還有我嗎？

在所有機器前面部署一層MQ，平時每秒幾百請求大家都可以輕鬆接收訊息。 一旦到了瞬時高峰期，一下湧入每秒幾千的請求，就可以積壓在MQ裡面，然後那一臺機器慢慢的處理和消費。

總結：削峰從本質上來說就是更多地延緩使用者請求，以及層層過濾使用者的訪問需求，遵從“最後落地到資料庫的請求數要儘量少”的原則。

總結

解耦與複用

系統A要傳送一個訊息到多個系統，如果此時每增加一個系統，系統A都需要透過修改原始碼來增加介面，此時耦合非常高，但是如果中間使用訊息佇列的話，系統只需要傳送一次到訊息佇列，別的系統就能複用該資訊，當增加或刪除系統呼叫介面的時候，不需要額外的更新程式碼。

非同步

使用者呼叫一個介面的時候，可能該介面呼叫了別的方法。例如：使用者註冊的時候，後臺可能需要呼叫：查詢資料庫，插入資料庫，傳送郵件，傳送使用者指南等等。。。

但是使用者可能並不需要後臺將所有的任務執行完畢，那麼此時在初入資料口後面加入mq佇列，使用者就能很快得到註冊成功的響應而去做一些別的事情。mq的機制又能保證最終的一致性，所以使用起來很安全很穩定。

削峰

何為削峰，就是當系統壓力過大的時候，讓系統壓力減小。如何做？

比如，平時可能資料庫的讀寫每秒幾百，在流量高峰期，系統的訪問達到了每秒10000。此時由於加入了訊息佇列，所以不會出現激增的訪問導致系統奔潰。

削峰並不會讓使用者的等待時間減少，所以一般會跟非同步搭配來使用

最後MQ還有其他場景，通知、資料分發等等，能體現使用MQ中介軟體的好處。