1??????什么是RabbitMQ？

RabbitMQ是實(shí)現(xiàn)AMQP（高級(jí)消息隊(duì)列協(xié)議）的消息中間件的一種，最初起源于金融系統(tǒng)，用于在分布式系統(tǒng)中存儲(chǔ)轉(zhuǎn)發(fā)消息，在易用性、擴(kuò)展性、高可用性等方面表現(xiàn)不俗。消息中間件主要用于組件之間的解耦，消息的發(fā)送者無需知道消息使用者的存在，反之亦然：

?

單向解耦

?

雙向解耦（如：RPC）

????例如一個(gè)日志系統(tǒng)，很容易使用RabbitMQ簡化工作量，一個(gè)Consumer可以進(jìn)行消息的正常處理，另一個(gè)Consumer負(fù)責(zé)對消息進(jìn)行日志記錄，只要在程序中指定兩個(gè)Consumer所監(jiān)聽的queue以相同的方式綁定到同一個(gè)exchange即可，剩下的消息分發(fā)工作由RabbitMQ完成。
?

?

使用RabbitMQ server需要：

1. ErLang語言包；

2. RabbitMQ安裝包；

RabbitMQ同時(shí)提供了java的客戶端（一個(gè)jar包）。

?

2??????概念和特性

2.1??????交換機(jī)（exchange）：

1.?接收消息，轉(zhuǎn)發(fā)消息到綁定的隊(duì)列。四種類型：direct, topic, headers and fanout

direct：轉(zhuǎn)發(fā)消息到routigKey指定的隊(duì)列

topic：按規(guī)則轉(zhuǎn)發(fā)消息（最靈活）

headers：（這個(gè)還沒有接觸到）

fanout：轉(zhuǎn)發(fā)消息到所有綁定隊(duì)列

2.?如果沒有隊(duì)列綁定在交換機(jī)上，則發(fā)送到該交換機(jī)上的消息會(huì)丟失。

3.?一個(gè)交換機(jī)可以綁定多個(gè)隊(duì)列，一個(gè)隊(duì)列可以被多個(gè)交換機(jī)綁定。

4. topic類型交換器通過模式匹配分析消息的routing-key屬性。它將routing-key和binding-key的字符串切分成單詞。這些單詞之間用點(diǎn)隔開。它同樣也會(huì)識(shí)別兩個(gè)通配符：#匹配0個(gè)或者多個(gè)單詞，*匹配一個(gè)單詞。例如，binding key：*.stock.#匹配routing key：usd.stcok和eur.stock.db，但是不匹配stock.nana。

還有一些其他的交換器類型，如header、failover、system等，現(xiàn)在在當(dāng)前的RabbitMQ版本中均未實(shí)現(xiàn)。

5.?因?yàn)榻粨Q器是命名實(shí)體，聲明一個(gè)已經(jīng)存在的交換器，但是試圖賦予不同類型是會(huì)導(dǎo)致錯(cuò)誤?？蛻舳诵枰?jiǎng)h除這個(gè)已經(jīng)存在的交換器，然后重新聲明并且賦予新的類型。

6.?交換器的屬性：

-?持久性：如果啟用，交換器將會(huì)在server重啟前都有效。

-?自動(dòng)刪除：如果啟用，那么交換器將會(huì)在其綁定的隊(duì)列都被刪除掉之后自動(dòng)刪除掉自身。

-?惰性：如果沒有聲明交換器，那么在執(zhí)行到使用的時(shí)候會(huì)導(dǎo)致異常，并不會(huì)主動(dòng)聲明。

?

2.2??????隊(duì)列（queue）：

1.?隊(duì)列是RabbitMQ內(nèi)部對象，存儲(chǔ)消息。相同屬性的queue可以重復(fù)定義。

2.?臨時(shí)隊(duì)列。channel.queueDeclare()，有時(shí)不需要指定隊(duì)列的名字，并希望斷開連接時(shí)刪除隊(duì)列。

3.?隊(duì)列的屬性：

-?持久性：如果啟用，隊(duì)列將會(huì)在server重啟前都有效。

-?自動(dòng)刪除：如果啟用，那么隊(duì)列將會(huì)在所有的消費(fèi)者停止使用之后自動(dòng)刪除掉自身。

-?惰性：如果沒有聲明隊(duì)列，那么在執(zhí)行到使用的時(shí)候會(huì)導(dǎo)致異常，并不會(huì)主動(dòng)聲明。

-?排他性：如果啟用，隊(duì)列只能被聲明它的消費(fèi)者使用。

這些性質(zhì)可以用來創(chuàng)建例如排他和自刪除的transient或者私有隊(duì)列。這種隊(duì)列將會(huì)在所有鏈接到它的客戶端斷開連接之后被自動(dòng)刪除掉。它們只是短暫地連接到server，但是可以用于實(shí)現(xiàn)例如RPC或者在AMQ上的對等通信。4. RPC的使用是這樣的：RPC客戶端聲明一個(gè)回復(fù)隊(duì)列，唯一命名（例如用UUID），并且是自刪除和排他的。然后它發(fā)送請求給一些交換器，在消息的reply-to字段中包含了之前聲明的回復(fù)隊(duì)列的名字。RPC服務(wù)器將會(huì)回答這些請求，使用消息的reply-to作為routing key（默認(rèn)綁定器會(huì)綁定所有的隊(duì)列到默認(rèn)交換器，名稱為“amp.交換器類型名”）發(fā)送到默認(rèn)交換器。注意這僅僅是慣例而已，可以根據(jù)和RPC服務(wù)器的約定，它可以解釋消息的任何屬性（甚至數(shù)據(jù)體）來決定回復(fù)給誰。

2.3??????消息傳遞：

1.?消息在隊(duì)列中保存，以輪詢的方式將消息發(fā)送給監(jiān)聽消息隊(duì)列的消費(fèi)者，可以動(dòng)態(tài)的增加消費(fèi)者以提高消息的處理能力。

2.?為了實(shí)現(xiàn)負(fù)載均衡，可以在消費(fèi)者端通知RabbitMQ，一個(gè)消息處理完之后才會(huì)接受下一個(gè)消息。

channel.basic_qos(prefetch_count=1)

注意：要防止如果所有的消費(fèi)者都在處理中，則隊(duì)列中的消息會(huì)累積的情況。

3.?消息有14個(gè)屬性，最常用的幾種：

deliveryMode：持久化屬性

contentType：編碼

replyTo：指定一個(gè)回調(diào)隊(duì)列

correlationId：消息id

實(shí)例代碼：

4.?消息生產(chǎn)者可以選擇是否在消息被發(fā)送到交換器并且還未投遞到隊(duì)列（沒有綁定器存在）和/或沒有消費(fèi)者能夠立即處理的時(shí)候得到通知。通過設(shè)置消息的mandatory和/或immediate屬性為真，這些投遞保障機(jī)制的能力得到了強(qiáng)化。

5.?此外，一個(gè)生產(chǎn)者可以設(shè)置消息的persistent屬性為真。這樣一來，server將會(huì)嘗試將這些消息存儲(chǔ)在一個(gè)穩(wěn)定的位置，直到server崩潰。當(dāng)然，這些消息肯定不會(huì)被投遞到非持久的隊(duì)列中。

?

2.4??????高可用性（HA）：

1.?消息ACK，通知RabbitMQ消息已被處理，可以從內(nèi)存刪除。如果消費(fèi)者因宕機(jī)或鏈接失敗等原因沒有發(fā)送ACK（不同于ActiveMQ，在RabbitMQ里，消息沒有過期的概念），則RabbitMQ會(huì)將消息重新發(fā)送給其他監(jiān)聽在隊(duì)列的下一個(gè)消費(fèi)者。

channel.basicConsume(queuename, noAck=false, consumer);

2.?消息和隊(duì)列的持久化。定義隊(duì)列時(shí)可以指定隊(duì)列的持久化屬性（問：持久化隊(duì)列如何刪除？）

channel.queueDeclare(queuename, durable=true, false, false, null);

發(fā)送消息時(shí)可以指定消息持久化屬性：

channel.basicPublish(exchangeName, routingKey,

????????????MessageProperties.PERSISTENT_TEXT_PLAIN,

????????????message.getBytes());

這樣，即使RabbitMQ服務(wù)器重啟，也不會(huì)丟失隊(duì)列和消息。

3. publisher confirms

4. master/slave機(jī)制，配合Mirrored Queue，這種情況下，publisher會(huì)正常發(fā)送消息和接收消息的confirm，但對于subscriber來說，需要接收Consumer Cancellation Notifications來得到主節(jié)點(diǎn)失敗的通知，然后re-consume from the queue，此時(shí)要求client有處理重復(fù)消息的能力。注意：如果queue在一個(gè)新加入的節(jié)點(diǎn)上增加了一個(gè)slave，此時(shí)slave上沒有此前queue的信息（目前還沒有同步機(jī)制）。

（通過命令行或管理插件可以查看哪個(gè)slave是同步的：

rabbitmqctl list_queues name slave_pids synchronised_slave_pids）

????當(dāng)一個(gè)slave重新加入mirrored-queue時(shí)，如果queue是durable的，則會(huì)被清空。

?

2.5??????集群（cluster）：

1.?不支持跨網(wǎng)段（如需支持，需要shovel或federation插件）

2.?可以隨意的動(dòng)態(tài)增加或減少、啟動(dòng)或停止節(jié)點(diǎn)，允許節(jié)點(diǎn)故障

3.?集群分為RAM節(jié)點(diǎn)和DISK節(jié)點(diǎn)，一個(gè)集群最好至少有一個(gè)DISK節(jié)點(diǎn)保存集群的狀態(tài)。

4.?集群的配置可以通過命令行，也可以通過配置文件，命令行優(yōu)先。

?

3??????使用

3.1??????簡易使用流程
?

3.2??????RabbitMQ在OpenStack中的使用

?

?

????在Openstack中，組件之間對RabbitMQ使用基本都是“Remote Procedure Calls”的方式。每一個(gè)Nova服務(wù)（比如計(jì)算服務(wù)、存儲(chǔ)服務(wù)等）初始化時(shí)會(huì)創(chuàng)建兩個(gè)隊(duì)列，一個(gè)名為“NODE-TYPE.NODE-ID”，另一個(gè)名為“NODE-TYPE”，NODE-TYPE是指服務(wù)的類型，NODE-ID指節(jié)點(diǎn)名稱。

????從抽象層面上講，RabbitMQ的組件的使用類似于下圖所示：

每個(gè)服務(wù)會(huì)綁定兩個(gè)隊(duì)列到同一個(gè)topic類型的exchange，從不同的隊(duì)列中接收不同類型的消息。消息的發(fā)送者如果關(guān)心消息的返回值，則會(huì)監(jiān)聽另一個(gè)隊(duì)列，該隊(duì)列綁定在一個(gè)direct類型的exchange。接受者收到消息并處理后，會(huì)將消息的返回發(fā)送到此exchange。

在Openstack中，如果不關(guān)心消息返回，消息的流程圖如下：

?

????如果關(guān)心消息返回值，流程圖如下：

?

?

3.3??????為什么要使用RabbitMQ？

曾經(jīng)有過一個(gè)人做過一個(gè)測試（ http://www.cnblogs.com/amityat/archive/2011/08/31/2160293.html ），發(fā)送1百萬個(gè)并發(fā)消息，對性能有很高的需求，于是作者對比了RabbitMQ、MSMQ、ActiveMQ、ZeroMQueue，整個(gè)過程共產(chǎn)生1百萬條1K的消息。測試的執(zhí)行是在一個(gè)Windows Vista上進(jìn)行的，測試結(jié)果如下：

????雖然ZeroMQ性能較高，但這個(gè)產(chǎn)品不提供消息持久化，需要自己實(shí)現(xiàn)審計(jì)和數(shù)據(jù)恢復(fù)，因此在易用性和HA上不是令人滿意，通過測試結(jié)果可以看到，RabbitMQ的性能確實(shí)不錯(cuò)。

????我在本機(jī)也做了一些測試，但我的測試是基于組件的原生配置，沒有做任何的配置優(yōu)化，因此總覺的不靠譜。我只測試了RabbitMQ和ActiveMQ兩款產(chǎn)品，雖然網(wǎng)上都說ActiveMQ性能不如前者，但平心而論，ActiveMQ提供了很多配置，存在很大的調(diào)優(yōu)空間，也許修改一個(gè)配置參數(shù)就會(huì)使組件的性能有一個(gè)質(zhì)的飛躍。

關(guān)于RabbitMQ