1 簡介

RabbitMQ是一個開源的AMQP實現，服務器端用Erlang語言編寫，支持多種客戶端，如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等，支持AJAX。用于在分布式系統中存儲轉發消息，在易用性、擴展性、高可用性等方面表現不俗。 且RabbitMQ是基于 AMQP 協議的，目前各個互聯網大廠都在使用RabbitMQ作為消息中間件。

附上官網地址： https://www.rabbitmq.com/

2 特點

2.1 核心特點

• 采用Erlang語言作為底層實現：Erlang有著和原生Socket一樣的延遲

• 開源、性能優秀，穩定性保障

• 提供可靠性消息投遞模式（confirm）、返回模式（ return ）

• 與SpringAMQP完美的整合、API豐富

• 集群模式豐富，表達式配置，HA模式，鏡像隊列模型

• 保證數據不丟失的前提做到高可靠性、可用性

高性能原因：

• Erlang語言最初在于交換機領域的架構模式，這樣使得RabbitMQ在Broker之間進行數據交互的性能非常優秀

• Erlang有著和原生Socket一樣的延遲

2.2 專業術語

• 生產者（Producer）：發送消息的應用。

• 消費者（Consumer）：接收消息的應用。

• Server：又稱Broker，接受客戶端連接，實現AMQP實體服務

• Connection：連接、應用程序與Broker的網絡連接

• Channel：網絡信道，幾乎所有的操作都在Channel中進行，Channel是進行消息讀寫的通道。客戶端可建立多個Channel，每個Channel代表一個會話任務

• Message：消息，服務器和應用程序之間傳送的數據，由Properties和Body組成。Properties可以對消息進行修飾，比如消息的優先級，延遲等高級特性；Body則就是消息體內容

• Virtual host：虛擬主機，用于進行邏輯隔離，最上層的消息路由。一個Virtual host里面可以有若干個Exchange和Queue，同一個Virtual Host里面不能有相同名稱的Exchange或Queue

• Exchange：交換機、接收消息。根據路由鍵轉發消息到綁定的隊列

• Binding：Exchange和Queue之間的虛擬連接，binding中可以包含routing key

• Routing key：一個路由規則，虛擬機可用它確定如何路由一個特定消息

• Queue：也稱Message Queue，消息隊列，保存消息并將它們轉發給消費者

3 核心功能

3.1 AMQP

基礎模型

v2-370a909a995cde466c4965b51b6782dd_720w.jpg

AMQP，即Advanced Message Queuing Protocol，一個提供統一消息服務的應用層標準高級消息隊列協議，是應用層協議的一個開放標準，為面向消息的中間件設計。基于此協議的客戶端與消息中間件可傳遞消息，并不受客戶端/中間件不同產品，不同的開發語言等條件的限制。Erlang中的實現有RabbitMQ等。

它可以使對應的客戶端（client）與對應的消息中間件（broker）進行交互。消息中間件從發布者（publisher）那里收到消息（發布消息的應用，也稱為producer），然后將他們轉發給消費者（consumers，處理消息的應用）。由于AMQP是一個網絡協議，所以發布者、消費者以及消息中間件可以部署到不同的物理機器上面。

雖然在同步消息通訊的世界里有很多公開標準（如 COBAR的 IIOP ，或者是 SOAP 等），但是在異步消息處理中卻不是這樣，只有大企業有一些商業實現（如微軟的 MSMQ ，IBM 的 Websphere MQ 等），因此，在 2006 年的 6 月，Cisco 、Redhat、iMatix 等聯合制定了 AMQP 的公開標準。

RabbitMQ是由RabbitMQ Technologies Ltd開發并且提供商業支持的。該公司在2010年4月被SpringSource（VMWare的一個部門）收購。在2013年5月被并入Pivotal。其實VMWare，Pivotal和EMC本質上是一家的。不同的是VMWare是獨立上市子公司，而Pivotal是整合了EMC的某些資源，現在并沒有上市。

3.2 基礎架構

780135-20210209091458529-1809465892.png

3.3 交換器

3.3.1 交換機屬性

Exchange

• Type：交換機類型 direct、topic、fanout、headers

• Durability：是否需要持久化 ，默認為 true 表示持久化

• Auto Delete：當最后一個綁定到Exchange上的隊列刪除后，自動刪除該Exchange

• Internal：當前Exchange是否用于RabbitMQ內部使用，默認為False

• Arguments：擴展參數，用于擴展AMQP協議自制定化使用Name：交換機名稱

3.3.2 交換器類型

生產者發送消息到 RabbitMQ 的交換器上。常用的交換器有四種：

• fanout 。會把所有發送到該交換器的消息路由到與該交換器綁定的消息隊列中。

• Direct。會把消息路由到bingingKey 和RoutingKey 完全匹配的隊列中。

• Topic。Topic 類型的交換器哎在 direct 匹配規則上進行了擴展，不是進行完全匹配，而是進行模糊匹配。匹配規則如下：BindingKey和RoutingKey一樣都是由"."分隔的字符串；BindingKey中可以存在兩種特殊字符“” 和 “#”，用于模糊匹配，其中""用于匹配一個單詞，"#"用于匹配多個單詞（可以是0個）。

• Headers 。Handers 類型的交換器不是根據路由匹配規則來的，而是根據消息中的 headers 屬性進行匹配的。在綁定隊列和交換器時指定一組鍵值對，當發送的消息到交換器時，RabbitMQ會獲取到該消息的headers，對比其中的鍵值對是否完全匹配隊列和交換器綁定時指定的鍵值對，如果匹配，消息就會路由到該隊列。headers類型的交換器性能很差，不實用。

3.4 消息流程

• 生產者（producer）把消息發送給交換機。創建交換機的時候指定上面的交換機類型。

• 交換機（exchange）接收消息并且負責對消息進行路由。根據交換機的類型，消息的多個屬性會被使用，例如路由鍵。

• 綁定（binding）需要從交換機到隊列的這種方式來進行創建。在這個例子里，我們可以看到交換機有到兩個不同隊列的綁定。交換機根據消息的屬性來把消息分發到不同的隊列上。

• 消息（message）消息會一直留在隊列里直到被消費。

• 消費者（consumer）處理消息。

3.5 數據存儲

RabbitMQ消息有持久化消息和非持久化消息。

持久化消息在到達隊列時寫入磁盤，同時在內存中保存一份備份，當內存不足時，消息從內存中清除。

非持久化消息一般只存在內存中，當內存不足時進行數據的刷盤處理。節省內存空間。

RabbitMQ 存儲層包含兩部分，隊列索引和消息存儲。索引維護隊列的落盤消息的信息，比如存儲地點、是否已經被消費者接收，是否已經被消費者ack等，每個隊列都有相應的索引。

索引使用順序的段文件來存儲，后綴為 .idx ，文件名從0開始累加，每個段文件中包含固定的記錄數，默認是16384 ，每個index從磁盤中讀取消息的時候，都會在內中中維護一段文件。

消息存儲。消息通過鍵值對的形式存儲到文件中，一個虛擬主機上的所有隊列使用同一塊存儲，每個接地那只有一個。存儲分為：

• 持久化存儲。在broker 重啟后不會丟失。

• 臨時存儲。在broker 重啟后會丟失。

存儲方式為文件來存儲，后綴為 .rdq 。經過store 處理的所有消息都會以追加的方式寫入到該文件中，當文件達到指定容量時，會創建一個新的文件進行寫入。

讀取消息時，先根據消息的ID（msg_id）找到對應存儲的文件，如果文件存在并且未被鎖住，則直接打開文件，從指定位置讀取消息內容。如果文件不存在或者被鎖住了，則發送請求由store進行處理。

刪除消息時，只是從ETS表刪除指定消息的相關信息，同時更新消息對應的存儲文件和相關信息。在執行消息刪除操作時，并不立即對文件中的消息進行刪除，也就是說消息依然在文件中，僅僅是標記為垃圾數據而已。當一個文件中都是垃圾數據時可以將這個文件刪除。當檢測到前后兩個文件中的有效數據可以合并成一個文件，并且所有的垃圾數據的大小和所有文件（至少有3個文件存在的情況下）的數據大小的比值超過設置的閾值garbage_fraction（默認值0.5）時，才會觸發垃圾回收，將這兩個文件合并，執行合并的兩個文件一定是邏輯上相鄰的兩個文件。

4 相關信息

• 博文不易，辛苦各位猿友點個關注和贊，感謝