1.對MQ的介紹
說明是MQ

MQ(message queue)，從字面意思上看，本質是個佇列，FIFO 先入先出，只不過佇列中存放的內容是

message 而已，還是一種跨程序的通訊機制，用於上下游傳遞訊息。在網際網路架構中，MQ 是一種非常常

見的上下游“邏輯解耦+物理解耦”的訊息通訊服務。使用了 MQ 之後，訊息傳送上游只需要依賴 MQ，不

用依賴其他服務。

MQ的好處

流量消峰

舉個例子，如果訂單系統最多能處理一萬次訂單，這個處理能力應付正常時段的下單時綽綽有餘，正常時段我們下單一秒後就能返回結果。但是在高峰期，如果有兩萬次下單作業系統是處理不了的，只能限制訂單超過一萬後不允許使用者下單。使用訊息佇列做緩衝，我們可以取消這個限制，把一秒內下的訂單分散成一段時間來處理，這時有些使用者可能在下單十幾秒後才能收到下單成功的操作，但是比不能下單的體驗要好。

應用解耦

以電商應用為例，應用中有訂單系統、庫存系統、物流系統、支付系統。使用者建立訂單後，如果耦合呼叫庫存系統、物流系統、支付系統，任何一個子系統出了故障，都會造成下單操作異常。當轉變成基於訊息佇列的方式後，系統間呼叫的問題會減少很多，比如物流系統因為發生故障，需要幾分鐘來修復。在這幾分鐘的時間裡，物流系統要處理的記憶體被快取在訊息佇列中，使用者的下單操作可以正常完成。當物流系統恢復後，繼續處理訂單資訊即可，使用者感受不到物流系統的故障，提升系統的可用性。https://www.cnblogs.com/java0011/p/15167447.html

非同步處理

有些服務間呼叫是非同步的，例如 A 呼叫 B，B 需要花費很長時間執行，但是 A 需要知道 B 什麼時候可以執行完，以前一般有兩種方式，A 過一段時間去呼叫 B 的查詢 api 查詢。或者 A 提供一個 callback api， B 執行完之後呼叫 api 通知 A 服務。這兩種方式都不是很優雅，使用訊息匯流排，可以很方便解決這個問題，A 呼叫 B 服務後，只需要監聽 B 處理完成的訊息，當 B 處理完成後，會發送一條訊息給 MQ，MQ 會將此訊息轉發給 A 服務。這樣 A 服務既不用迴圈呼叫 B 的查詢 api，也不用提供 callback api。同樣 B 服務也不用做這些操作。A 服務還能及時的得到非同步處理成功的訊息。

2.RabbitMQ的六種模式 及工作原理

工作模式

依次是：hello world ，工作模式，釋出訂閱模式，路由模式，主題模式，釋出確認模式

工作原理

Binding：exchange 和 queue 之間的虛擬連線，binding 中可以包含 routing key，Binding 資訊被保

存到 exchange 中的查詢表中，用於 message 的分發依據

依賴

<!--rabbitmq 依賴客戶端-->
<dependency>
  <groupId>com.rabbitmq</groupId>
  <artifactId>amqp-client</artifactId>
  <version>5.8.0</version>
</dependency>

3.hello world佇列

1. 生產者