RabbitMq--AMQP高級消息隊列協議--簡單瞭解

1、安裝

Rabbitmq 是用 erlang 語言寫的，因此使用還要安裝 Erlang。

安裝 erlang 還要安裝 python 與 simplejson，我環境中已經安裝了 python 2.6.4，simplejson 只要 easy_install 就能夠了

安裝Python、Erlang、SimpleJson請看紅薯的博客：http://www.oschina.net/question/12_7840

2、瞭解

高級消息隊列協議（AMQP） 是一個異步消息傳遞所使用的應用層協議規範。做爲線路層協議，而不是API（例如JMS），AMQP 客戶端可以無視消息的來源任意發送和接受信息。如今，已經有至關一部分不一樣平臺的服務器和 客戶端能夠投入使用。

隊列是一個先入先出的數據結構。路由封裝了消息 隊列中的消息的相關信息，這些信息決定了消息在異步消息系統中的最終展示形式。

異步消息是一個很是普通而且普遍使用的技術，從例如Skype或者XMPP/Jabber這樣各類各樣的即時消息協議到 古老的email。可是，這些服務都有以下特徵：

- 它們會在傳輸消息的時候或多或少加入一些隨意的內容（例如一封email可能會包含一個文本和關於辦公室笑話的PPT）和一些比較正式的路由信息（例如 email地址）：正式的路由信息+隨意的信息

- 它們都是異步的，也就是說它們將生產者和消費者區分開來，所以可能將消息加入隊列（例如某人發給你一條消息，可是你不在線或者你的郵箱會收到一封 email）：不須要等待消息被處理後的返回值

- 生產者和消費者是具備不一樣知識的不一樣角色。我不須要知道你的IMAP用戶名和密碼就可以給你發送email。事實上，我甚至不須要知道你的email地址 是不是一個馬甲或者「真實」地址。這個特性意味着生產者不能控制什麼內容被閱讀或者訂閱了 （只管發，不關心消息是否被使用）- 就像個人email客戶端會捨棄掉大多數主動發送給個人醫藥廣告。

AMQP是一個抽象的協議（也就是說它不負責處理具體的數據），這個事實並不會將事情變得更復雜。反而，Internet使得消息無處不在。

AMQ模型

在AMQ規範中描述了一些實體。一個用來分辨這些實體的方法是檢查它們是否由服務器管理員配置或者由客戶端在運行的時候聲明。

可配置的實體有：

- 消息協商器（Message Broker），它在TCP/IP等端口監聽AMQ消息。

- 將消息協商數據劃分到多個不一樣集合的虛擬主機，它很像webserver中的虛擬主機，例如Apache的http守護進程。

- 使用安全憑據鏈接到虛擬主機的用戶。

值得注意的是，規範中僅僅授予用戶訪問虛擬主機的權限，並無採納其餘比這高級的訪問控制措施，所以RabbitMQ並不支持這些高級訪問控制措 施。--用戶角色權限分配目前並不支持，可由廠商擴展。

爲了和協商器交流，一個客戶端須要創建一個或者多個鏈接。這些鏈接只是限於鏈接用戶和虛擬主機。客戶端默認使用guest/guest訪問權限和訪問虛擬主機的根目錄，這些默認實現也是RabbitMQ的默認安裝選項。

在一個鏈接中，客戶端聲明瞭一個通道，經過單一鏈接到協商器的併發控制須要創建一個可靠的模型，這裏可使用通道池和串行訪問或者例如線程本地通道這樣的線程併發模型。

若是須要在一個通道上進行操做，那麼客戶端須要聲明AMQ組件。聲明組件是斷言特定的組件存在於協商器中──若是不存在的話，那麼在運行時建立。

這些組件包括：

- 交換器（Exchange），它是發送消息的實體。

- 隊列（Queue），這是接收消息的實體。

- 綁定器（Bind），將交換器和隊列鏈接起來，而且封裝消息的路由信息。

客戶端能夠經過交換器的名字來發送消息，也能夠經過隊列的名字收取信息。

綁定器沒有名字，它們的生命期依賴於所緊密鏈接的交換器和隊列。若是這二者任意一個被刪除掉，那麼綁定器便失效了。這就說明，若要知道交換器和隊列 的名字，還須要設置消息路由。

消息是一個不透明的數據包，這些包有以下性質：

- 元數據-數據的數據（數據描述），例如內容的編碼或者代表來源的字段。

- 標誌位，標記消息投遞時候的一些保障機制。

- 一個特殊的字段叫作routing key。

3、使用

3.1接受和發送消息：交換器類型
發送消息是一個很是簡單的過程。客戶端聲明一個它想要發送消息的目的交換器，而後將消息傳遞給交換器。接受消息的最簡單辦法是設置一個訂閱。客戶端須要聲明一個隊列，而且使用一個綁定器將以前的交換器和隊列綁定起來，這樣的話，訂閱就設置完畢。

1 require 'rubygems'
2 require 'mq'
3
4 event_loop = Thread.new do
5   EM.run do
6     EM.add_timer(1) do
7       EM.stop
8     end
9   end
10 end
11
12 def subscribe_to_queue
13
14   exchange = MQ.fanout('my-fanout-exchange')
15   queue = MQ.queue('my-fanout-queue')
16
17   queue.bind(exchange).subscribe do |header, body|
18     yield header, body
19   end
20
21 end
22
23 def send_to_exchange(message)
24
25   exchange = MQ.fanout('my-fanout-exchange')
26   exchange.publish message
27
28 end
29
30 subscribe_to_queue do |header, body|
31   p "I received a message: #{body}"
32 end
33
34 send_to_exchange 'Hello'
35 send_to_exchange 'World'
36
37 event_loop.join

三個標準決定了一條消息是否真的被投遞到了隊列中：

1. 交換器的類型。在這個例子中類型是fanout。
2. 消息的屬性。在這個例子中，消息沒有任何屬性，只是有內容（首先是Hello，而後World）。
3. 給定的綁定器的惟一可選屬性：鍵值。在這個例子中綁定器沒有任何鍵值。

--------明見：http://www.oschina.net/question/12_9192