1. 什麼是 MQ
1.1 概念
MQ 全拼 Message Queue 即 消息隊列。是在消息的傳輸過程中保存消息的容器，多用於分佈式系統。
1.2 MQ 帶來的優勢
MQ 所帶來的優勢即我們用 MQ 的理由，如下：
- 應用解耦：複雜系統增加消息隊列中間層解耦兩端邏輯。提高系統容錯性和可維護性
- 異步處理：消息異步處理，加快服務響應速度。提升用戶體驗和系統吞吐量
- 削峯填谷，流量控制：系統從消息隊列中拉取消費請求，由消息隊列緩衝量併發請求。請求量大可削峯，請求量小可填谷。提高系統穩定性
實際案例場景：
秒殺、聊天、等
1.3 MQ 帶來的問題
所謂 天下沒有免費的午餐，有利就有弊，引入 MQ 同樣也會給我們帶來不少問題：
- 增加了系統複雜度和維護成本。
- 引入消息隊列所帶來的延遲問題。
- 可能存在的數據不一致問題。
利弊權衡間考慮你的系統是否需要引入消息隊列。
2. RabbitMQ 簡介
公司/社區: Rabbit
開發語言：Erlang （爲高併發和分佈式誕生的語言，電信領域使用廣泛）
協議支持：AMQP、XMPP、SMTP、STOMP
客戶端支持語言：官方支持 Erlang、Java、Ruby 等，社區提供幾乎支持所有主流語言。
單機吞吐量： 萬級
消息延遲： 微秒
功能特性：併發能力強，性能極好，低延遲，社區活躍，完善的管理界面。
下圖是一個簡單的模型，以及一些相關概念
2.1 什麼是 AMQP
AMQP 全稱 Advanced Message Queuing Protocol 即 高級消息隊列協議，是一個應用層網絡協議，專門面向消息隊列的中間件進行設計的協議。基於此協議的客戶端與消息中間件可以傳遞消息，不受不同 客戶端/中間件/開發語言等條件限制。是一個通信規範。
2.2 基礎架構模型
名詞解釋：
Broker： 中間件，接收和分發消息的應用，如 RabbitMQ Server 就是 Message Broker （消息中間件）
Virtual host：虛擬主機，出於多租戶和安全的考慮，把 AMQP 的基本組件劃分到一個虛擬的分組中，類似於網絡中 namespace 命名空間的概念。當多個用戶使用同一個 RabbitMQ server 所提供的服務時，可以劃分出多個 virtual host ，每個用戶在自己的 virtual host 進行 exchange 以及 queue 等，互不干擾。
Connection 鏈接，publisher 發佈者 、consumer 訂閱者 與 broker 之間的 TCP 鏈接。
Channel：通道，管道。 channel 是在 connection 內部建立的邏輯鏈接，爲了避免程序多線程而創建多個 connection 做的優化。 如果應用程序支持多線程，通常每個 thread 會創建單獨的 channel 進行通訊， AMQP Method 包含了 channelId 幫助客戶端和 message broker 識別 channel ，每個 channel 相互隔離。這個概念有點類似 進行和線程的對應關係，正好一個進程對應一個 connection ，一個線程對應一個 channel 這樣的感覺。
Exchange：交換機，message 到達 broker 會先進過 交換機 ，根據分發規則，查表匹配 routing key ，將消息分發到對應的 queue。常用的類型： direct （point-to-point），topic（publish-subscribe）、fanout （multicast）後文會詳細說明。
Queue：隊列，消息最終存儲位置，等待 consumer 消費。
Binding: exchange 與 queue 之間的虛擬鏈接，binding 中可以包含 routing key。binding 信息被保存到 exchange 的查詢表中，用於消息的分發。
RabbitMQ 6 種工作模式
https://www.rabbitmq.com/getstarted.html
1. Hello World 模式
這個模式簡單理解就是 一對一的消費模式，一個生產者對應一個消費者，消息僅消費一次。
2. Work queues 工作隊列模式
工作隊列模式，與上面的簡單模式區別是 可以多個生產者，然後由多個消費者一起消費消息，消息僅消費一次，對應的可以提高消息的處理速度。
3. Publish/Subscribe 發佈訂閱模式
到這裏，發佈訂閱模式，路由模式，主題模式 其實結構上大同小異，區別僅僅是 交換機 Exchange 的綁定路由規則不同罷了。
同時在該模式下，一份消息會分發給符合條件的多個隊列使用，且比上面的模式多了交換機的概念。
交換機 顧名思義 作用就是將生產者生產的消息，根據一定的規則分發到對應的隊列中。
發佈訂閱模式的 Exchange 交換機是 Fanout 廣播模式，即：將消息交給所有綁定到交換機的隊列
4. Routing 路由模式
路由模式的 Exchange 交換機是 Direct 定向模式，即：把消息交給 routing key 路由對應的隊列
5. Topics 主題模式
主題模式的 Exchange 交換機是 Topic 通配符模式，即：把消息交給 routing pattern 路由匹配的隊列
6. RPC 遠程調用模式
RPC 不是消息隊列的重點，這裏不做過多解釋。RPC 有更多成熟的框架實現，個人不建議使用消息隊列來實現。
消息的可靠性
消息生產端的可靠投遞
在使用 RabbitMQ 的時候，作爲消息發送方希望杜絕任何消息丟失或者投遞失敗場景。RabbitMQ 爲我們提供了兩種方式用來控制消息的投遞可靠性模式。
confirm 確認模式
return 退回模式
rabbitmq 整個消息投遞的路徑爲：
producer—>rabbitmq broker—>exchange—>queue—>consumer
消息從 producer 到 exchange 投遞失敗會返回一個 confirmCallback 。
消息從 exchange–>queue 投遞失敗會返回一個 returnCallback 。
我們將利用這兩個 callback 控制消息的可靠性投遞
注意這兩個模式需要進行配置開啓。如：
publisher-confirms=“true” 確認模式開啓
publisher-returns=“true” 回退模式開啓
消費端的確認消費 ACK
RabbitMQ 在消費端提供了 3 種確認機制
無需確認 acknowledge = "none" 該模式下無需手動編寫代碼 ack 。RabbitMQ 默認 consumer 正確處理所有請求。
手動確認 acknowledge="manual" 該模式下需要手動編寫代碼進行消息確認 如正常收到消息 channel.basicAck() 消息異常 channel.basicNack() 等。
自動確認 acknowledge="auto" consumer 自動應答，處理成功（即沒有發生異常）發出 ack，處理失敗發出 nack。queue 發出消息後會等待 consumer 端應答，只有收到 ack 確定信息後纔會將消息在 queue 中清除掉。收到 nack 異常信息的處理方法由setDefaultRequeueReject() 方法設置，這種模式下，發送錯誤的消息可以恢復。
Java 代碼編寫
關於 Java 代碼編寫使用上，一般有 三種 方式
純 Java 代碼方式
Spring 配置方式
Spring Boot 自動配置方式
