RabbitMQ-一、基本概念

RabbitMQ

一、基本概念

RabbitMQ是一個開源的AMQP(高級消息隊列協議)實現，服務器端用Erlang語言編寫，支持多種客戶端，如：Ruby、.NET、Java、C、PHP等，

RabbitMQ 是一個消息代理，主要接受、存儲和轉發消息。你可以把它想象成郵局：當你將一個包裹送到郵局，郵局會暫存並最終將郵件由郵遞員送到接件人手上，RabbitMQ就好比一個郵局、郵箱和郵遞員。

RabbitMQ是一個生產者、消費者模型

1.Producer

Producer(生產者)，產生消息並向RabbitMq發送消息, 一般用下圖表示Producer：

2.Consumer

Consumer(消費者),等待RabbitMq消息到來並處理消息，一般使用下圖表示Consumer:

3.Queue

Queue(隊列), 依存於RabbitMQ內部, 雖然消息通過RabbitMQ在你的應用中傳遞，但是它們只能存儲在queue中。隊列不受任何限制，可以存儲任何數量的消息—本質上是一個無限制的緩存。很多producers可以通過同一個隊列發送消息，相同的很多consumers可以從同一個隊列上接收消息。一般用下圖表示隊列：

注意：producer（生產者）,consumer（消費者）,broker（RabbitMQ服務）並不需要部署在同一臺機器上，實際上在大多數實際的應用中，也不會部署在同一臺機器上。

4.Message acknowledgment

在實際應用中，可能會發生消費者收到Queue中的消息，但沒有處理完成就宕機（或出現其他意外）的情況，這種情況下就可能會導致消息丟失。爲了避免這種情況發生，我們可以要求消費者在消費完消息後發送一個回執給RabbitMQ，RabbitMQ收到消息回執（Message acknowledgment）後纔將該消息從Queue中移除；如果RabbitMQ沒有收到回執並檢測到消費者的RabbitMQ連接斷開，則RabbitMQ會將該消息發送給其他消費者（如果存在多個消費者）進行處理。這裏不存在timeout概念，一個消費者處理消息時間再長也不會導致該消息被髮送給其他消費者，除非它的RabbitMQ連接斷開。

 

這裏會產生另外一個問題，如果我們的開發人員在處理完業務邏輯後，忘記發送回執給RabbitMQ，這將會導致嚴重的bug——Queue中堆積的消息會越來越多；消費者重啓後會重複消費這些消息並重復執行業務邏輯。(消費者處理完消息了，但在發送消息回執時消費者宕機了，回執沒有發送，還是會導致消息重複消費??)

 

另外pub message是沒有ack的。

5.Message durability

如果我們希望即使在RabbitMQ服務重啓的情況下，也不會丟失消息，我們可以將Queue與Message都設置爲可持久化的（durable），這樣可以保證絕大部分情況下我們的RabbitMQ消息不會丟失。但依然解決不了小概率丟失事件的發生（比如RabbitMQ服務器已經接收到生產者的消息，但還沒來得及持久化該消息時RabbitMQ服務器就斷電了），如果我們需要對這種小概率事件也要管理起來，那麼我們要用到事務。由於這裏僅爲RabbitMQ的簡單介紹，所以這裏將不講解RabbitMQ相關的事務。

6. Prefetch count

前面我們講到如果有多個消費者同時訂閱同一個Queue中的消息，Queue中的消息會被平攤給多個消費者。這時如果每個消息的處理時間不同，就有可能會導致某些消費者一直在忙，而另外一些消費者很快就處理完手頭工作並一直空閒的情況。我們可以通過設置prefetchCount來限制Queue每次發送給每個消費者的消息數，比如我們設置prefetchCount=1，則Queue每次給每個消費者發送一條消息；消費者處理完這條消息後Queue會再給該消費者發送一條消息。

7.Exchange

在上一節我們看到生產者將消息投遞到Queue中，實際上這在RabbitMQ中這種事情永遠都不會發生。實際的情況是，生產者將消息發送到Exchange（交換器，下圖中的X），由Exchange將消息路由到一個或多個Queue中（或者丟棄）。

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了。

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。

8.Exchange Types

RabbitMQ常用的Exchange Type有fanout、direct、topic、headers這四種。

fanout

fanout類型的Exchange路由規則非常簡單，它會把所有發送到該Exchange的消息路由到所有與它綁定的Queue中。

上圖中，生產者（P）發送到Exchange（X）的所有消息都會路由到圖中的兩個Queue，並最終被兩個消費者（C1與C2）消費。

direct

direct類型的Exchange路由規則也很簡單，它會把消息路由到那些binding key與routing key完全匹配的Queue中。

以上圖的配置爲例，我們以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中可以存在兩種特殊字符“*”與“#”，用於做模糊匹配，其中“*”用於匹配一個單詞，“#”用於匹配多個單詞（可以是零個）

以上圖中的配置爲例，

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=”orange”、routingKey=”quick.orange.male.rabbit”的消息將會被丟棄，因爲它們沒有匹配任何bindingKey。

headers

headers類型的Exchange不依賴於routingkey與binding key的匹配規則來路由消息，而是根據發送的消息內容中的headers屬性進行匹配。
在綁定Queue與Exchange時指定一組鍵值對；當消息發送到Exchange時，RabbitMQ會取到該消息的headers（也是一個鍵值對的形式），對比其中的鍵值對是否完全匹配Queue與Exchange綁定時指定的鍵值對；如果完全匹配則消息會路由到該Queue，否則不會路由到該Queue。
該類型的Exchange沒有用到過（不過也應該很有用武之地），所以不做介紹。

參考：

http://blog.csdn.net/anzhsoft/article/details/19563091

http://blog.csdn.net/whycold/article/details/41119807