RabbitMQ 總體上是一個生產者與消費者模型，主要負責接收、存儲和轉發消息。能夠把消息傳遞的過程想象成：當你講一個包裹送到郵局，郵局會暫存並最終將郵件經過郵遞員送到收件人的手上，RabbitMQ 就比如由郵局、郵箱和郵遞員組成的一個系統。從計算機術語層面來講，RabbitMQ 模型更像是一種交換機模型。java
RabbitMQ 的總體模型架構以下圖：服務器
生產者和消費者
Producer：生產者，就是投遞消息的一方。架構
生產者建立消息，而後發不到 RabbitMQ 中。消息通常能夠包含 2 個部分：消息體和標籤（Label）。消息體也能夠稱之爲 payload，在實際應用中，消息體通常是一個帶有業務邏輯結構的數據，好比一個 JSON 字符串。固然能夠進一步對這個消息體進行序列化操做。消息的標籤用來表述這條消息，好比一個交換器的名稱和一個路由鍵。生產者把消息交由 RabbitMQ，RabbitMQ 以後會根據標籤把消息發送給感興趣的消費者（Consumer）。post
Consumer：消費者，就是接收消息的一方。性能
消費者鏈接到 RabbitMQ 服務器，並訂閱到隊列上。當消費者消費一條消息時，只是消費消息的消息體（payload）。在消息路由的過程當中，消息的標籤會丟棄，存入到隊列中的消息只有消息體，消費者也會消費到消息體，也就不知道消息的生產者是誰，固然消費者也不須要知道。spa
Broker：消息中間件的服務節點。線程
對於 RabbitMQ 來講，一個 RabbitMQ Broker 能夠簡單地看做一個 RabbitMQ 服務節點，或者 RabbitMQ 服務實例。大多數狀況下也能夠將一個 RabbitMQ Broker 看做一臺 RabbitMQ 服務器。翻譯
下圖展現了生產者將消息存入 RabbitMQ Broker，以及消費者從 Broker 中消費數據的整個流程。debug
首先生產者將業務方數據進行可能的包裝，以後封裝成消息，發送（AMQP 協議裏這個動做對應的命令爲 Basic.Publish）到 Broker 中。消費者訂閱並接收消息（AMQP 協議裏這個動做對應的命令爲 Basic.Consume 或者 Basic.Get），通過可能的解包處理獲得原始的數據，以後再進行業務處理邏輯。這個業務處理邏輯並不必定須要和接收消息的邏輯使用同一個線程。消費者線程可使用一個線程去接收消息，存入到內存中，好比使用 Java 中的 BlockingQueue。業務處理邏輯使用另外一個線程從內存中讀取數據，這樣能夠將應用進一步解耦，提升整個應用的處理效率。3d
隊列
Queue：隊列，是 RabbitMQ 的內部對象，用於存儲消息。
RabbitMQ 中消息只能存儲在隊列中，這一點和 Kafka 這種消息隊列中間件相反。Kafka 將消息存儲在 topic（主題）這個邏輯層面，而相對應的隊列處理邏輯只是 topic 實際存儲文件中的位移標識。RabbitMQ 的生產者生產消息並最終投遞到隊列中，消費者能夠從隊列中獲取消息並消費。
多個消費者能夠訂閱同一個隊列，這時隊列中的消息會被平均分攤（Round-Robin，即輪詢）給多個消費者進行處理，而不是每一個消費者都接收到全部的消息並處理。
RabbitMQ 不支持隊列層面的廣播消費，若是須要廣播消費，須要在其上進行二次開發，處理邏輯會變得異常複雜，同時也不建議這麼作。
交換器、路由鍵、綁定
Exchange：交換器。在圖 2-4 中咱們暫時能夠理解成生產者將消息投遞到隊列中，實際上這個在 RabbitMQ 中不會發生。真實狀況是，生產者將消息發送到 Exchange（交換器，一般也能夠用大寫的 "X" 來表示），由交換器將消息路由到一個或者多個隊列中。若是路由不到，或許會返回給生產者，或許直接丟棄。這裏能夠將 RabbitMQ 中的交換器看做一個簡單的實體。
RabbitMQ 中的交換器有四種類型，不一樣的類型有着不一樣的路由策略。
RoutingKey：路由鍵。生產者將消息發給交換器的時候，通常會指定一個 RoutingKey，用來指定這個消息的路由規則，而這個 RoutingKey 須要與交換器類型和 綁定鍵（BindingKey）聯合起來才能最終生效。
在交換器類型和綁定鍵（BindingKey）固定的狀況下，生產者能夠在發送消息給交換器時，經過指定 RoutingKey 來決定消息流向哪裏。
Binding：綁定。RabbitMQ 中經過綁定將 交換器與隊列關聯起來，在綁定的時候通常會指定一個綁定鍵（BindingKey），這樣 RabbitMQ 就指定如何正確地將消息路由到隊列了。
生產者將消息發送給交換器，須要一個 RoutingKey，當 BindingKey 和 RoutingKey 相匹配時，消息會被路由到對應的隊列中。在綁定多個隊列到同一個交換器的時候，這些綁定容許使用相同的 BindingKey。BindingKey 並很多在全部的狀況下都生效，它依賴於交換器類型，好比 fanout 類型的交換器就會無視 BindingKey，而是將消息路由到全部綁定到該交換器的隊列中。
沿用本文開頭的比喻，交換器至關於投遞包裹的郵箱，RoutingKey 至關於寫在包裹上的地址，BindingKey 至關於包裹的目的地，當填寫在包裹上的地址和實際想要投遞的地址相匹配時，那麼這個包裹就會被正確投遞到目的地，最後這個目的地的 "主人" -- 隊列能夠保留這個包裹。若是填寫的地址出錯，郵遞員不能正確投遞到目的地，包裹可能會回退給寄件人，也有可能被丟棄。
在某些情形下，RoutingKey 與 BindingKey 能夠看做同一個東西。
|
1
2
3
4
5
6
7
|
channel.exchangeDeclare(EXCHANGE_NAME,
"direct"
,
true
,
false
,
null
);
channel.queueDeclare(QUEUE_NAME,
true
,
false
,
false
,
null
);
channel.queueBind(QUEUE_NAME, EXCHANGE_NAME, ROUTING_KEY);
String message =
"Hello World!"
;
channel.basicPublic(EXCHANGE_NAME, ROUTING_KEY,
MessageProperties.PERSISTENT_TEXT_PLAIN,
message.getBytes());
|
以上代碼聲明瞭一個 direct 類型的交換器，而後將交換器和隊列綁定起來。注意這裏使用的字樣是 "ROUTING_KEY"，在本該使用 BindingKey 的 channel.queueBind 方法中卻和 channel.basicPublish 方法一樣使用了 RoutingKey，這樣作的潛臺詞是：這裏的 RoutingKey 和 BindingKey 是同一個東西。在 direct 交換器類型下，RoutingKey 和 BindingKey 須要徹底匹配才能使用，因此上面的代碼中採用了這種寫法會顯得方便許多。
可是在 topic 交換器類型下，RoutingKey 和 BindingKey 之間須要作模糊匹配，二者並非相同的。
BingingKey 其實也屬於路由鍵的一種，官方解釋爲：the routing key to use for the binding。能夠翻譯爲：在綁定的時候使用的路由鍵。大多數時候，包括官方文檔和 RabbitMQ Java API 中都把 BindingKey 和 RoutingKey 看做 RoutingKey，爲了不混淆，能夠這麼理解：
在綁定的時候，其中須要的路由鍵是 BindingKey。涉及的客戶端方法如： channel.exchangeBind、channel.queueBind，對應 AMQP 命令爲 Exchange.Bind、Queue.Bind。
發送消息的時候，其中須要的路由鍵是 RoutingKey。涉及的客戶端方法如 channel.basicPublish，對應的 AMQP 命令爲 Basic.Publish。
因爲某些歷史的緣由，包括現存能蒐集到的資料顯示：大多數狀況下習慣性地將 BindingKey 寫成 RoutingKey，尤爲是在使用 direct 類型的交換器的時候。
交換器類型
RabbitMQ 經常使用的交換器類型有 fanout、direct、topic、headers 這四種。AMQP 協議裏還提到另外兩種類型：System 和自定義。
fanout
它會把全部發送到該交換器的消息路由到全部與該交換器綁定的隊列中。
direct
direct 類型的交換器路由規則也很簡單，它會把消息路由到那些 BindingKey 和 RoutingKey 徹底匹配的隊列中。
如下圖爲例，交換器的類型爲 direct，若是咱們發送一條消息，並在發送消息的時候設置路由鍵爲 "warning"，消息會路由到 Queue1 和 Queue2，對應的示例代碼以下：
|
1
2
3
|
channel.basicPublish(EXCHANGE_NAME,
"warning"
,
MessageProperties.PERSISTENT_TEXT_PLAIN,
message.getbytes());
|
若是 在發送消息的時候設置路由鍵爲 "info" 或者 "debug"，消息只會路由到 Queue2。若是以其餘的路由鍵發送消息，則消息不會路由到這兩個隊列中。
topic
前面講到 direct 類型的交換器路由規則是徹底匹配 BindingKey 和 RoutingKey，可是這種嚴格的匹配方式在不少狀況下不能知足實際業務的需求。topic 類型的交換器在匹配規則上進行了擴展，它與 direct 類型的交換器類似，也是將消息路由到 BindingKey 和 RoutingKey 相匹配的隊列中，但這裏的匹配規則有些不一樣，它約定：
RoutingKey 爲一個點號 "." 分隔的字符串（被點號 "." 分隔開的每一段獨立的字符串成爲一個單詞），如 "com.rabbitmq.client"、"java.util.concurrent"、"com.hidden.client"；
BindingKey 和 RoutingKey 同樣也是點號 ".' 分隔的字符串
BindingKey 中能夠存在兩種特殊字符串 "*" 和 "#"，用於作模糊匹配，其中 "*" 用於匹配一個單詞, "#" 用於匹配多個單詞（能夠是零個）
以圖 2-8 中的配置爲例：
路由鍵爲 "com.rabbitmq.client" 的消息會同時路由到 Queue1 和 Queue2；
路由鍵爲 "com.hidden.client" 的消息只會路由到 Queue2；
路由鍵爲 "com.hidden.demo" 的消息只會路由到 Queue2；
路由鍵爲 "java.util.concurrent" 的消息將會被丟棄或者返回給生產者（須要設置 mandatory 參數），由於它沒有匹配任何路由鍵。
headers
headers 類型的交換器不依賴於路由鍵的匹配規則來路由消息，而是根據發送的消息內容中的 headers 屬性進行匹配。在綁定隊列和交換器時指定一組鍵值對，當發送消息到交換器時，RabbitMQ 會獲取到該消息的 headers（也是一個鍵值對的形式），對比其中的鍵值對是否徹底匹配隊列和交換器綁定時指定的鍵值對，若是徹底匹配則消息會路由到該隊列，不然不會路由到該隊列。headers 類型的交換器性能會不好，並且也不實用，基本上不會看到它的存在。