1. 歷史
RabbitMQ是一個由erlang開發的AMQP（Advanced Message Queue ）的開源實現。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的某些資源，現在並沒有上市。
RabbitMQ的官網是http://www.rabbitmq.com
2. 應用場景
言歸正傳。RabbitMQ，或者說AMQP解決了什麼問題，或者說它的應用場景是什麼？
對於一個大型的軟件系統來說，它會有很多的組件或者說模塊或者說子系統或者（subsystem or Component or submodule）。那麼這些模塊的如何通信？這和傳統的IPC有很大的區別。傳統的IPC很多都是在單一系統上的，模塊耦合性很大，不適合擴展（Scalability）；如果使用socket那麼不同的模塊的確可以部署到不同的機器上，但是還是有很多問題需要解決。比如：
- 1）信息的發送者和接收者如何維持這個連接，如果一方的連接中斷，這期間的數據如何方式丟失？
- 2）如何降低發送者和接收者的耦合度？
- 3）如何讓Priority高的接收者先接到數據？
- 4）如何做到load balance？有效均衡接收者的負載？
- 5）如何有效的將數據發送到相關的接收者？也就是說將接收者subscribe 不同的數據，如何做有效的filter。
- 6）如何做到可擴展，甚至將這個通信模塊發到cluster上？
- 7）如何保證接收者接收到了完整，正確的數據？ AMDQ協議解決了以上的問題，而RabbitMQ實現了AMQP。
3. 系統架構
image.png
RabbitMQ Server： 也叫broker server，它不是運送食物的卡車，而是一種傳輸服務。原話是RabbitMQisn’t a food truck, it’s a delivery service. 他的角色就是維護一條從Producer到Consumer的路線，保證數據能夠按照指定的方式進行傳輸。但是這個保證也不是100%的保證，但是對於普通的應用來說這已經足夠了。當然對於商業系統來說，可以再做一層數據一致性的guard，就可以徹底保證系統的一致性了。
Client P： 也叫Producer，數據的發送方。createmessages and publish (send) them to a broker server (RabbitMQ).一個Message有兩個部分：payload（有效載荷）和label（標籤）。payload顧名思義就是傳輸的數據。label是exchange的名字或者說是一個tag，它描述了payload，而且RabbitMQ也是通過這個label來決定把這個Message發給哪個Consumer。AMQP僅僅描述了label，而RabbitMQ決定了如何使用這個label的規則。
Client C: 也叫Consumer，數據的接收方。Consumersattach to a broker server (RabbitMQ) and subscribe to a queue。把queue比作是一個有名字的郵箱。當有Message到達某個郵箱後，RabbitMQ把它發送給它的某個訂閱者即Consumer。當然可能會把同一個Message發送給很多的Consumer。在這個Message中，只有payload，label已經被刪掉了。對於Consumer來說，它是不知道誰發送的這個信息的。就是協議本身不支持。但是當然瞭如果Producer發送的payload包含了Producer的信息就另當別論了。
對於一個數據從Producer到Consumer的正確傳遞，還有三個概念需要明確：exchanges, queues and bindings。
Exchanges are where producers publish their messages.
Queues are where the messages end up and are received by consumers
Bindings are how the messages get routed from the exchange to particular queues.
還有幾個概念是上述圖中沒有標明的，那就是Connection（連接），Channel（通道，頻道）。
Connection： 就是一個TCP的連接。Producer和Consumer都是通過TCP連接到RabbitMQ Server的。以後我們可以看到，程序的起始處就是建立這個TCP連接。
Channels： 虛擬連接。它建立在上述的TCP連接中。數據流動都是在Channel中進行的。也就是說，一般情況是程序起始建立TCP連接，第二步就是建立這個Channel。
那麼，爲什麼使用Channel，而不是直接使用TCP連接？
對於OS來說，建立和關閉TCP連接是有代價的，頻繁的建立關閉TCP連接對於系統的性能有很大的影響，而且TCP的連接數也有限制，這也限制了系統處理高併發的能力。但是，在TCP連接中建立Channel是沒有上述代價的。對於Producer或者Consumer來說，可以併發的使用多個Channel進行Publish或者Receive。有實驗表明，1s的數據可以Publish10K的數據包。當然對於不同的硬件環境，不同的數據包大小這個數據肯定不一樣，但是我只想說明，對於普通的Consumer或者Producer來說，這已經足夠了。如果不夠用，你考慮的應該是如何細化split你的設計。
Broker： 簡單來說就是消息隊列服務器實體。
Exchange： 消息交換機，它指定消息按什麼規則，路由到哪個隊列。
Queue： 消息隊列載體，每個消息都會被投入到一個或多個隊列。 Binding： 綁定，它的作用就是把exchange和queue按照路由規則綁定起來。
Routing Key： 路由關鍵字，exchange根據這個關鍵字進行消息投遞。
vhost： 虛擬主機，一個broker裏可以開設多個vhost，用作不同用戶的權限分離。
producer： 消息生產者，就是投遞消息的程序。 consumer： 消息消費者，就是接受消息的程序。 channel： 消息通道，在客戶端的每個連接裏，可建立多個channel，每個channel代表一個會話任務。
由Exchange，Queue，RoutingKey三個才能決定一個從Exchange到Queue的唯一的線路。
4.基本概念
ConnectionFactory、Connection、Channel
ConnectionFactory、Connection、Channel都是RabbitMQ對外提供的API中最基本的對象。Connection是RabbitMQ的socket鏈接，它封裝了socket協議相關部分邏輯。ConnectionFactory爲Connection的製造工廠。
Channel是我們與RabbitMQ打交道的最重要的一個接口，我們大部分的業務操作是在Channel這個接口中完成的，包括定義Queue、定義Exchange、綁定Queue與Exchange、發佈消息等。
Queue
Queue（隊列）是RabbitMQ的內部對象，用於存儲消息，用下圖表示。 queue
image.png
RabbitMQ中的消息都只能存儲在Queue中，生產者（下圖中的P）生產消息並最終投遞到Queue中，消費者（下圖中的C）可以從Queue中獲取消息並消費。
image.png
多個消費者可以訂閱同一個Queue，這時Queue中的消息會被平均分攤給多個消費者進行處理，而不是每個消費者都收到所有的消息並處理。
image.png
Message acknowledgment
在實際應用中，可能會發生消費者收到Queue中的消息，但沒有處理完成就宕機（或出現其他意外）的情況，這種情況下就可能會導致消息丟失。爲了避免這種情況發生，我們可以要求消費者在消費完消息後發送一個回執給RabbitMQ，RabbitMQ收到消息回執（Message acknowledgment）後纔將該消息從Queue中移除；如果RabbitMQ沒有收到回執並檢測到消費者的RabbitMQ連接斷開，則RabbitMQ會將該消息發送給其他消費者（如果存在多個消費者）進行處理。這裏不存在timeout概念，一個消費者處理消息時間再長也不會導致該消息被髮送給其他消費者，除非它的RabbitMQ連接斷開。
這裏會產生另外一個問題，如果我們的開發人員在處理完業務邏輯後，忘記發送回執給RabbitMQ，這將會導致嚴重的bug——Queue中堆積的消息會越來越多；消費者重啓後會重複消費這些消息並重復執行業務邏輯。
另外pub message是沒有ack的。
Message durability
如果我們希望即使在RabbitMQ服務重啓的情況下，也不會丟失消息，我們可以將Queue與Message都設置爲可持久化的（durable），這樣可以保證絕大部分情況下我們的RabbitMQ消息不會丟失。但依然解決不了小概率丟失事件的發生（比如RabbitMQ服務器已經接收到生產者的消息，但還沒來得及持久化該消息時RabbitMQ服務器就斷電了），如果我們需要對這種小概率事件也要管理起來，那麼我們要用到事務。由於這裏僅爲RabbitMQ的簡單介紹，所以這裏將不講解RabbitMQ相關的事務。
Prefetch count
前面我們講到如果有多個消費者同時訂閱同一個Queue中的消息，Queue中的消息會被平攤給多個消費者。這時如果每個消息的處理時間不同，就有可能會導致某些消費者一直在忙，而另外一些消費者很快就處理完手頭工作並一直空閒的情況。我們可以通過設置prefetchCount來限制Queue每次發送給每個消費者的消息數，比如我們設置prefetchCount=1，則Queue每次給每個消費者發送一條消息；消費者處理完這條消息後Queue會再給該消費者發送一條消息。
image.png
Exchange
在上一節我們看到生產者將消息投遞到Queue中，實際上這在RabbitMQ中這種事情永遠都不會發生。實際的情況是，生產者將消息發送到Exchange（交換器，下圖中的X），由Exchange將消息路由到一個或多個Queue中（或者丟棄）。
image.png
Exchange是按照什麼邏輯將消息路由到Queue的？這個將在Binding一節介紹。
RabbitMQ中的Exchange有四種類型，不同的類型有着不同的路由策略，這將在Exchange Types一節介紹。
routing key
生產者在將消息發送給Exchange的時候，一般會指定一個routing key，來指定這個消息的路由規則，而這個routing key需要與Exchange Type及binding key聯合使用才能最終生效。
在Exchange Type與binding key固定的情況下（在正常使用時一般這些內容都是固定配置好的），我們的生產者就可以在發送消息給Exchange時，通過指定routing key來決定消息流向哪裏。
RabbitMQ爲routing key設定的長度限制爲255 bytes。
Binding
RabbitMQ中通過Binding將Exchange與Queue關聯起來，這樣RabbitMQ就知道如何正確地將消息路由到指定的Queue了。
image.png
Binding key
在綁定（Binding）Exchange與Queue的同時，一般會指定一個binding key；消費者將消息發送給Exchange時，一般會指定一個routing key；當binding key與routing key相匹配時，消息將會被路由到對應的Queue中。這個將在Exchange Types章節會列舉實際的例子加以說明。 在綁定多個Queue到同一個Exchange的時候，這些Binding允許使用相同的binding key。
binding key 並不是在所有情況下都生效，它依賴於Exchange Type，比如fanout類型的Exchange就會無視binding key，而是將消息路由到所有綁定到該Exchange的Queue。
Exchange Types
RabbitMQ常用的Exchange Type有fanout、direct、topic、headers這四種（AMQP規範裏還提到兩種Exchange Type，分別爲system與自定義，這裏不予以描述），下面分別進行介紹。
fanout
fanout類型的Exchange路由規則非常簡單，它會把所有發送到該Exchange的消息路由到所有與它綁定的Queue中。
image.png
上圖中，生產者（P）發送到Exchange（X）的所有消息都會路由到圖中的兩個Queue，並最終被兩個消費者（C1與C2）消費。
direct
direct類型的Exchange路由規則也很簡單，它會把消息路由到那些binding key與routing key完全匹配的Queue中。
image.png
以上圖的配置爲例，我們以routingKey=”error”發送消息到Exchange，則消息會路由到Queue1（amqp.gen-S9b…，這是由RabbitMQ自動生成的Queue名稱）和Queue2（amqp.gen-Agl…）；如果我們以routingKey=”info”或routingKey=”warning”來發送消息，則消息只會路由到Queue2。如果我們以其他routingKey發送消息，則消息不會路由到這兩個Queue中。
topic
前面講到direct類型的Exchange路由規則是完全匹配binding key與routing key，但這種嚴格的匹配方式在很多情況下不能滿足實際業務需求。topic類型的Exchange在匹配規則上進行了擴展，它與direct類型的Exchage相似，也是將消息路由到binding key與routing key相匹配的Queue中，但這裏的匹配規則有些不同，它約定：
routing key爲一個句點號“.”分隔的字符串（我們將被句點號“. ”分隔開的每一段獨立的字符串稱爲一個單詞），如“stock.usd.nyse”、“nyse.vmw”、“quick.orange.rabbit” binding key與routing key一樣也是句點號“. ”分隔的字符串 binding key中可以存在兩種特殊字符“*”與“#”，用於做模糊匹配，其中“*”用於匹配一個單詞，“#”用於匹配多個單詞（可以是零個）
image.png
以上圖中的配置爲例，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。
headers
headers類型的Exchange不依賴於routing key與binding key的匹配規則來路由消息，而是根據發送的消息內容中的headers屬性進行匹配。
在綁定Queue與Exchange時指定一組鍵值對；當消息發送到Exchange時，RabbitMQ會取到該消息的headers（也是一個鍵值對的形式），對比其中的鍵值對是否完全匹配Queue與Exchange綁定時指定的鍵值對；如果完全匹配則消息會路由到該Queue，否則不會路由到該Queue。
該類型的Exchange沒有用到過（不過也應該很有用武之地），所以不做介紹。
RPC
MQ本身是基於異步的消息處理，前面的示例中所有的生產者（P）將消息發送到RabbitMQ後不會知道消費者（C）處理成功或者失敗（甚至連有沒有消費者來處理這條消息都不知道）。
但實際的應用場景中，我們很可能需要一些同步處理，需要同步等待服務端將我的消息處理完成後再進行下一步處理。這相當於RPC（Remote Procedure Call，遠程過程調用）。
在RabbitMQ中也支持RPC。
image.png
RabbitMQ中實現RPC的機制是：
- 客戶端發送請求（消息）時，在消息的屬性（MessageProperties，在AMQP協議中定義了14中properties，這些屬性會隨着消息一起發送）中設置兩個值replyTo（一個Queue名稱，用於告訴服務器處理完成後將通知我的消息發送到這個Queue中）和correlationId（此次請求的標識號，服務器處理完成後需要將此屬性返還，客戶端將根據這個id瞭解哪條請求被成功執行了或執行失敗）
- 服務器端收到消息並處理
- 服務器端處理完消息後，將生成一條應答消息到replyTo指定的Queue，同時帶上correlationId屬性
- 客戶端之前已訂閱replyTo指定的Queue，從中收到服務器的應答消息後，根據其中的correlationId屬性分析哪條請求被執行了，根據執行結果進行後續業務處理
5. 細節闡明
使用ack確認Message的正確傳遞
默認情況下，如果Message 已經被某個Consumer正確的接收到了，那麼該Message就會被從queue中移除。當然也可以讓同一個Message發送到很多的Consumer。
如果一個queue沒被任何的Consumer Subscribe（訂閱），那麼，如果這個queue有數據到達，那麼這個數據會被cache，不會被丟棄。當有Consumer時，這個數據會被立即發送到這個Consumer，這個數據被Consumer正確收到時，這個數據就被從queue中刪除。
那麼什麼是正確收到呢？通過ack。每個Message都要被acknowledged（確認，ack）。我們可以顯示的在程序中去ack，也可以自動的ack。如果有數據沒有被ack，那麼RabbitMQ Server會把這個信息發送到下一個Consumer。
如果這個app有bug，忘記了ack，那麼RabbitMQ Server不會再發送數據給它，因爲Server認爲這個Consumer處理能力有限。
而且ack的機制可以起到限流的作用（Benefitto throttling）：在Consumer處理完成數據後發送ack，甚至在額外的延時後發送ack，將有效的balance Consumer的load。
當然對於實際的例子，比如我們可能會對某些數據進行merge，比如merge 4s內的數據，然後sleep 4s後再獲取數據。特別是在監聽系統的state，我們不希望所有的state實時的傳遞上去，而是希望有一定的延時。這樣可以減少某些IO，而且終端用戶也不會感覺到。
Reject a message
有兩種方式，第一種的Reject可以讓RabbitMQ Server將該Message 發送到下一個Consumer。第二種是從queue中立即刪除該Message。
Creating a queue
Consumer和Procuder都可以通過 queue.declare 創建queue。對於某個Channel來說，Consumer不能declare一個queue，卻訂閱其他的queue。當然也可以創建私有的queue。這樣只有app本身纔可以使用這個queue。queue也可以自動刪除，被標爲auto-delete的queue在最後一個Consumer unsubscribe後就會被自動刪除。那麼如果是創建一個已經存在的queue呢？那麼不會有任何的影響。需要注意的是沒有任何的影響，也就是說第二次創建如果參數和第一次不一樣，那麼該操作雖然成功，但是queue的屬性並不會被修改。
那麼誰應該負責創建這個queue呢？是Consumer，還是Producer？
如果queue不存在，當然Consumer不會得到任何的Message。但是如果queue不存在，那麼Producer Publish的Message會被丟棄。所以，還是爲了數據不丟失，Consumer和Producer都try to create the queue！反正不管怎麼樣，這個接口都不會出問題。
queue對load balance的處理是完美的。對於多個Consumer來說，RabbitMQ 使用循環的方式（round-robin）的方式均衡的發送給不同的Consumer。
Exchanges
從架構圖可以看出，Procuder Publish的Message進入了Exchange。接着通過“routing keys”， RabbitMQ會找到應該把這個Message放到哪個queue裏。queue也是通過這個routing keys來做的綁定。
有三種類型的Exchanges：direct, fanout,topic。 每個實現了不同的路由算法（routing algorithm）。
- Direct exchange: 如果 routing key 匹配, 那麼Message就會被傳遞到相應的queue中。其實在queue創建時，它會自動的以queue的名字作爲routing key來綁定那個exchange。
- Fanout exchange: 會向響應的queue廣播。
- Topic exchange:對key進行模式匹配，比如ab可以傳遞到所有ab的queue。
Virtual hosts
每個virtual host本質上都是一個RabbitMQ Server，擁有它自己的queue，exchagne，和bings rule等等。這保證了你可以在多個不同的application中使用RabbitMQ。