From：http://blog.csdn.net/column/details/rabbitmq.html

RabbitMQ 介紹

歷史

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

應用場景

言歸正傳。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。

系統架構

成為系統架構可能不太合適，可能叫應用場景的系統架構更合適。

這個系統架構圖版權屬於sunjun041640。

RabbitMQ Server：也叫broker server，它不是運送食物的卡車，而是一種傳輸服務。原話是RabbitMQisn’t a food truck, it’s a delivery service. 他的角色就是維護一條從Producer到Consumer的路線，保證資料能夠按照指定的方式進行傳輸。但是這個保證也不是100%的保證，但是對於普通的應用來說這已經足夠了。當然對於商業系統來說，可以再做一層資料一致性的guard，就可以徹底保證系統的一致性了。

Client A & B：也叫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 1，2，3：也叫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.

Queuesare 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你的設計。

進一步的細節闡明

使用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。

接下來我會使用Python來說明RabbitMQ的使用方法。

python 使用 RabbitMQ 寫 "Hello World"

http://www.rabbitmq.com/tutorials/tutorial-one-python.html

使用Python（pika 0.9.8）實現從Producer到Consumer傳遞資料”Hello, World“。

RabbitMQ實現了AMQP定義的訊息佇列。它實現的功能”非常簡單“：從Producer接收資料然後傳遞到Consumer。它能保證多併發，資料安全傳遞，可擴充套件。

和任何的Hello world一樣，它們都不復雜。我們將會設計兩個程式，一個傳送Hello world，另一個接收這個資料並且列印到螢幕。
整體的設計如下圖：

環境配置

RabbitMQ 實現了AMQP。因此，我們需要安裝AMPQ的library。幸運的是對於多種程式語言都有實現。我們可以使用以下lib的任何一個：

在這裡我們將使用pika. 可以通過 pip 包管理工具來安裝:

$ sudo pip install pika==0.9.8

這個安裝依賴於pip和Git-core。

On Ubuntu:

$ sudo apt-get install python-pip git-core

On Debian:

$ sudo apt-get install python-setuptools git-core
$ sudo easy_install pip

On Windows:To install easy_install, run the MS Windows Installer for setuptools
```
> easy_install pip
> pip install pika==0.9.8
```

Sending

第一個program send.py：傳送Hello world 到queue。正如我們在上篇文章提到的，你程式的第一句話就是建立連線，第二句話就是建立channel：

#!/usr/bin/env python  
import pika  
  
connection = pika.BlockingConnection(pika.ConnectionParameters(  
               'localhost'))  
channel = connection.channel()

建立連線傳入的引數就是RabbitMQ Server的ip或者name。關於誰建立queue，上面也討論過：Producer和Consumer都應該去建立。接下來我們建立名字為hello的queue：

channel.queue_declare(queue='hello')

建立了channel，我們可以通過相應的命令來list queue：

$ sudo rabbitmqctl list_queues  
Listing queues ...  
hello    0  
...done.

現在我們已經準備好了傳送了。

從架構圖可以看出，Producer只能傳送到exchange，它是不能直接傳送到queue的。

現在我們使用預設的exchange（名字是空字元）。這個預設的exchange允許我們傳送給指定的queue。routing_key就是指定的queue名字。

channel.basic_publish(exchange='',  
                      routing_key='hello',  
                      body='Hello World!')  
print " [x] Sent 'Hello World!'"

退出前別忘了關閉connection。

connection.close()

Receiving

第二個program receive.py 將從queue中獲取Message並且列印到螢幕。

第一步還是建立connection。第二步建立channel。第三步建立queue，name = hello：

channel.queue_declare(queue='hello')

接下來要subscribe了。在這之前，需要宣告一個回撥函式來處理接收到的資料。

def callback(ch, method, properties, body):  
    print " [x] Received %r" % (body,)

subscribe：

channel.basic_consume(callback,  
                      queue='hello',  
                      no_ack=True)

最後，準備好無限迴圈監聽吧：

print ' [*] Waiting for messages. To exit press CTRL+C'  
channel.start_consuming()

最終版本

send.py:

#!/usr/bin/env python  
import pika  
  
connection = pika.BlockingConnection(pika.ConnectionParameters(  
        host='localhost'))  
channel = connection.channel()  
  
channel.queue_declare(queue='hello')  
  
channel.basic_publish(exchange='',  
                      routing_key='hello',  
                      body='Hello World!')  
print " [x] Sent 'Hello World!'"  
connection.close()

receive.py:

#!/usr/bin/env python  
import pika  
  
connection = pika.BlockingConnection(pika.ConnectionParameters(  
        host='localhost'))  
channel = connection.channel()  
  
channel.queue_declare(queue='hello')  
  
print ' [*] Waiting for messages. To exit press CTRL+C'  
  
def callback(ch, method, properties, body):  
    print " [x] Received %r" % (body,)  
  
channel.basic_consume(callback,  
                      queue='hello',  
                      no_ack=True)  
  
channel.start_consuming()

最終執行

先執行 send.py program:

$ python send.py  
[x] Sent 'Hello World!'

send.py 每次執行完都會停止。注意：現在資料已經存到queue裡了。接收它：

$ python receive.py  
[*] Waiting for messages. To exit press CTRL+C  
[x] Received 'Hello World!'

任務分發機制

http://www.rabbitmq.com/tutorials/tutorial-two-Python.html

上面解決了從傳送端（Producer）向接收端（Consumer）傳送“Hello World”的問題。在實際的應用場景中，這是遠遠不夠的。現在將結合更加實際的應用場景來講解更多的高階用法。

當有Consumer需要大量的運算時，RabbitMQ Server需要一定的分發機制來balance每個Consumer的load。試想一下，對於web application來說，在一個很多的HTTP request裡是沒有時間來處理複雜的運算的，只能通過後臺的一些工作執行緒來完成。接下來我們分佈講解。

應用場景就是RabbitMQ Server會將queue的Message分發給不同的Consumer以處理計算密集型的任務：

準備

在上面，我們簡單在Message中包含了一個字串"Hello World"。現在為了是Consumer做的是計算密集型的工作，那就不能簡單的字串了。在現實應用中，Consumer有可能做的是一個圖片的resize，或者是pdf檔案的渲染或者內容提取。但是作為Demo，還是用字串模擬吧：通過字串中的.的數量來決定計算的複雜度，每個.都會消耗1s，即sleep(1)。

還是複用上面的code，根據“計算密集型”做一下簡單的修改，為了辨別，我們把send.py 的名字換成new_task.py

import sys  
  
message = ' '.join(sys.argv[1:]) or "Hello World!"  
channel.basic_publish(exchange='',  
                      routing_key='hello',  
                      body=message)  
print " [x] Sent %r" % (message,)

同樣的道理，把receive.py的名字換成worker.py，並且根據Message中的.的數量進行計算密集型模擬：

import time  
  
def callback(ch, method, properties, body):  
    print " [x] Received %r" % (body,)  
    time.sleep( body.count('.') )  
    print " [x] Done"

Round-robin dispatching 迴圈分發

RabbitMQ的分發機制非常適合擴充套件，而且它是專門為併發程式設計的。如果現在load加重，那麼只需要建立更多的Consumer來進行任務處理即可。當然了，對於負載還要加大怎麼辦？我沒有遇到過這種情況，那就可以建立多個virtual Host，細化不同的通訊類別了。

首先開啟兩個Consumer，即執行兩個worker.py。

Console1：

shell1$ python worker.py  
 [*] Waiting for messages. To exit press CTRL+C

Consule2：

shell2$ python worker.py  
 [*] Waiting for messages. To exit press CTRL+C

Producer new_task.py要Publish Message了：

shell3$ python new_task.py First message.  
shell3$ python new_task.py Second message..  
shell3$ python new_task.py Third message...  
shell3$ python new_task.py Fourth message....  
shell3$ python new_task.py Fifth message.....

注意一下：.代表的sleep(1)。接著開一下Consumer worker.py收到了什麼:

Console1：

shell1$ python worker.py  
 [*] Waiting for messages. To exit press CTRL+C  
 [x] Received 'First message.'  
 [x] Received 'Third message...'  
 [x] Received 'Fifth message.....'

Console2：

shell2$ python worker.py  
 [*] Waiting for messages. To exit press CTRL+C  
 [x] Received 'Second message..'  
 [x] Received 'Fourth message....'

預設情況下，RabbitMQ 會順序的分發每個Message。當每個收到ack後，會將該Message刪除，然後將下一個Message分發到下一個Consumer。這種分發方式叫做round-robin。這種分發還有問題，接著向下讀吧。

Message acknowledgment 訊息確認

每個Consumer可能需要一段時間才能處理完收到的資料。如果在這個過程中，Consumer出錯了，異常退出了，而資料還沒有處理完成，那麼非常不幸，這段資料就丟失了。因為我們採用no-ack的方式進行確認，也就是說，每次Consumer接到資料後，而不管是否處理完成，RabbitMQ Server會立即把這個Message標記為完成，然後從queue中刪除了。

如果一個Consumer異常退出了，它處理的資料能夠被另外的Consumer處理，這樣資料在這種情況下就不會丟失了（注意是這種情況下）。

為了保證資料不被丟失，RabbitMQ支援訊息確認機制，即acknowledgments。為了保證資料能被正確處理而不僅僅是被Consumer收到，那麼我們不能採用no-ack。而應該是在處理完資料後傳送ack。

在處理資料後傳送的ack，就是告訴RabbitMQ資料已經被接收，處理完成，RabbitMQ可以去安全的刪除它了。

如果Consumer退出了但是沒有傳送ack，那麼RabbitMQ就會把這個Message傳送到下一個Consumer。這樣就保證了在Consumer異常退出的情況下資料也不會丟失。

這裡並沒有用到超時機制。RabbitMQ僅僅通過Consumer的連線中斷來確認該Message並沒有被正確處理。也就是說，RabbitMQ給了Consumer足夠長的時間來做資料處理。

預設情況下，訊息確認是開啟的（enabled）。在上篇文章中我們通過no_ack = True 關閉了ack。重新修改一下callback，以在訊息處理完成後傳送ack：

def callback(ch, method, properties, body):  
    print " [x] Received %r" % (body,)  
    time.sleep( body.count('.') )  
    print " [x] Done"  
    ch.basic_ack(delivery_tag = method.delivery_tag)  
  
channel.basic_consume(callback,  
                      queue='hello')

這樣即使你通過Ctr-C中斷了worker.py，那麼Message也不會丟失了，它會被分發到下一個Consumer。

如果忘記了ack，那麼後果很嚴重。當Consumer退出時，Message會重新分發。然後RabbitMQ會佔用越來越多的記憶體，由於RabbitMQ會長時間執行，因此這個“記憶體洩漏”是致命的。去除錯這種錯誤，可以通過一下命令列印un-acked Messages：

$ sudo rabbitmqctl list_queues name messages_ready messages_unacknowledged  
Listing queues ...  
hello    0       0  
...done.

Message durability訊息持久化

在上一節中我們知道了即使Consumer異常退出，Message也不會丟失。但是如果RabbitMQ Server退出呢？軟體都有bug，即使RabbitMQ Server是完美毫無bug的（當然這是不可能的，是軟體就有bug，沒有bug的那不叫軟體），它還是有可能退出的：被其它軟體影響，或者系統重啟了，系統panic了。。。

為了保證在RabbitMQ退出或者crash了資料仍沒有丟失，需要將queue和Message都要持久化。

queue的持久化需要在宣告時指定durable=True：

channel.queue_declare(queue='hello', durable=True)

上述語句執行不會有什麼錯誤，但是確得不到我們想要的結果，原因就是RabbitMQ Server已經維護了一個叫hello的queue，那麼上述執行不會有任何的作用，也就是hello的任何屬性都不會被影響。這一點在上篇文章也討論過。

那麼workaround也很簡單，宣告一個另外的名字的queue，比如名字定位task_queue：

RabbitMQ從入門到精通

RabbitMQ 介紹

歷史

應用場景

系統架構

進一步的細節闡明

使用ack確認Message的正確傳遞

Reject a message

Creating a queue

Exchanges

Virtual hosts

python 使用 RabbitMQ 寫 "Hello World"

環境配置

Sending

Receiving

最終版本

最終執行

任務分發機制

準備

Round-robin dispatching 迴圈分發

Message acknowledgment 訊息確認

Message durability訊息持久化

關於持久化的進一步討論：

Fair dispatch 公平分發

最終版本

分發到多Consumer（Publish/Subscribe）

Exchanges

Temporary queues

Bindings繫結

最終版本

Routing 訊息路由

Bindings繫結

Direct exchange

Multiple bindings

Emitting logs

Subscribing

最終版本

使用主題進行訊息分發

Topic exchange

程式碼實現

執行和結果

適用於雲端計算叢集的遠端呼叫(RPC)

客戶端介面 Client interface

回撥函式佇列 Callback queue

Message properties

相關id Correlation id

總結

最終實現

RabbitMQ訊息佇列的小夥伴: ProtoBuf（Google Protocol Buffer）

Publisher的訊息確認機制

事務機制 VS Publisher Confirm

訊息在什麼時候確認

程式設計實現

相關文章