一、RabbitMQ簡介
1、RabbitMQ是一個開源的消息代理的隊列服務器，用來通過普通協議在完全不同的應用之間共享數據。
2、RabbitMQ是使用Erlang語言來編寫的，並且RabbitMQ是基於AMQP協議的。
3、Erlang語言在數據交互方面性能優秀，有着和原生Socket一樣的延遲，這也是RabbitMQ高性能的原因所在。
AMQP協議：Advanced Message Queue，高級消息隊列協議。它是應用層協議的一個開放標準，爲面向消息的中間件設計，基於此協議的客戶端與消息中間件可傳遞消息，並不受產品、開發語言等條件的限制。消息中間件主要用於組件之間的解耦，消息的發送者無需知道消息使用者的存在，反之亦然。
二、RabbitMQ特點
1、可靠性：RabbitMQ 使用一些機制來保證可靠性，如持久化、傳輸確認、發佈確認。
2、靈活的路由：在消息進入隊列之前，通過 Exchange 來路由消息的。對於典型的路由功能，RabbitMQ 已經提供了一些內置的 Exchange 來實現。針對更復雜的路由功能，可以將多個 Exchange 綁定在一起，也通過插件機制實現自己的 Exchange。
3、消息集羣：多個 RabbitMQ 服務器可以組成一個集羣，形成一個邏輯 Broker 。
4、高可用：隊列可以在集羣中的機器上進行鏡像，使得在部分節點出問題的情況下隊列仍然可用。
5、多種協議：RabbitMQ 支持多種消息隊列協議，比如 STOMP、MQTT 等等。
6、多語言客戶端：RabbitMQ 幾乎支持所有常用語言，比如 Java、.NET、Ruby 等等。
7、管理界面：RabbitMQ 提供了一個易用的用戶界面，使得用戶可以監控和管理消息 Broker 的許多方面。
8、跟蹤機制：如果消息異常，RabbitMQ 提供了消息跟蹤機制，使用者可以找出發生了什麼。
9、插件機制：RabbitMQ 提供了許多插件，來從多方面進行擴展，也可以編寫自己的插件。
三、RabbitMQ消息模型
所有 MQ 產品從模型抽象上來說都是一樣的過程，如下：
消費者（consumer）訂閱某個隊列。生產者（producer）創建消息，然後發佈到隊列（queue）中，最後將消息發送到監聽的消費者。
四、RabbitMQ核心概念
1、Broker：表示消息隊列服務器實體。接受客戶端的連接，實現AMQP實體服務。簡單來說就是消息隊列服務器實體。
2、Connection：網絡連接，比如一個TCP連接。應用程序與Broker的網絡連接。
3、Channel：網絡信道，幾乎所有的操作都在Channel中進行，Channel是進行消息讀寫的通道。客戶端可建立多個Channel，每個Channel代表一個會話任務。也就是說，一般情況是程序起始建立TCP連接，第二步就是建立這個Channel。
4、Message：消息，服務器和應用程序之間傳送的數據，由Properties和Body組成。Properties可以對消息進行修飾，比如消息的優先級、延遲等高級特性；Body則就是消息體內容。
5、Virtual host：虛擬地址，用於進行邏輯隔離，最上層的消息路由。一個Virtual Host裏面可以有若干個Exchange和Queue，同一個VirtualHost 裏面不能有相同名稱的Exchange或Queue。
五、各個具體流程
1、AMQP的消息路由過程
六、Exchange 說明
0、屬性
Durability：是否需要持久化 ，默認爲 true 表示持久化
Auto Delete：當最後一個綁定到Exchange上的隊列刪除後，自動刪除該Exchange
Internal：當前Exchange是否用於RabbitMQ內部使用，默認爲False
Arguments：擴展參數，用於擴展AMQP協議自制定化使用Name：交換機名稱
1、四種類型：direct、fanout、topic、headers
- headers：headers 匹配 AMQP 消息的 header 而不是路由鍵，此外 headers 交換器和 direct 交換器完全一致，但性能差很多，目前幾乎用不到了。direct：
- direct：類型的Exchange路由規則很簡單，它會把消息路由到那些binding key與routing key完全匹配的Queue中，不匹配的則不會轉發，它是單播的模式。如下圖：
![]()
- fanout：每個發到 fanout 類型交換器的消息都會分到所有綁定的隊列上去。fanout 交換器不處理路由鍵，只是簡單的將隊列綁定到交換器上，每個發送到交換器的消息都會被轉發到與該交換器綁定的所有隊列上，fanout 類型轉發消息是最快的。如下圖：
- topic：前面講到direct類型的Exchange路由規則是完全匹配binding key與routing key，但這種嚴格的匹配方式在很多情況下不能滿足實際業務需求。topic類型的Exchange在匹配規則上進行了擴展，它與direct類型的Exchage相似，也是將消息路由到binding key與routing key相匹配的Queue中，但這裏的匹配規則有些不同，它約定：
1、routing key爲一個句點號“. ”分隔的字符串（我們將被句點號“. ”分隔開的每一段獨立的字符串稱爲一個單詞），如“stock.usd.nyse”、“nyse.vmw”、“quick.orange.rabbit”
2、binding key與routing key一樣也是句點號“. ”分隔的字符串
3、binding key中可以存在兩種特殊字符“*”與“#”，用於做模糊匹配，其中“*”用於匹配一個單詞，“#”用於匹配多個單詞（可以是零個）
示意圖如下：
示意圖說明：以上圖中的配置爲例，routingKey=”quick.orange.rabbit”的消息會同時路由到Q1與Q2，routingKey=”lazy.orange.fox”的消息會路由到Q1，routingKey=”lazy.brown.fox”的消息會路由到Q2，routingKey=”lazy.pink.rabbit”的消息會路由到Q2（只會投遞給Q2一次，雖然這個routingKey與Q2的兩個bindingKey都匹配）；routingKey=”quick.brown.fox”、routingKey=”orange”、routingKey=”quick.orange.male.rabbit”的消息將會被丟棄，因爲它們沒有匹配任何bindingKey。
其他示意圖：
