前言：

    MQ 是什么？隊(duì)列是什么，MQ 我們可以理解為消息隊(duì)列，隊(duì)列我們可以理解為管道。以管道的方式做消息傳遞。

場(chǎng)景：

    1.其實(shí)我們?cè)陔p11的時(shí)候，當(dāng)我們凌晨大量的秒殺和搶購(gòu)商品，然后去結(jié)算的時(shí)候，就會(huì)發(fā)現(xiàn)，界面會(huì)提醒我們，讓我們稍等，以及一些友好的圖片文字提醒。而不是像前幾年的時(shí)代，動(dòng)不動(dòng)就頁(yè)面卡死，報(bào)錯(cuò)等來(lái)呈現(xiàn)給用戶(hù)。

    在這業(yè)務(wù)場(chǎng)景中，我們就可以采用隊(duì)列的機(jī)制來(lái)處理，因?yàn)橥瑫r(shí)結(jié)算就只能達(dá)到這么多。

    2.在我們平時(shí)的超市中購(gòu)物也是一樣，當(dāng)我們?cè)诮Y(jié)算的時(shí)候，并不會(huì)一窩蜂一樣涌入收銀臺(tái)，而是排隊(duì)結(jié)算。這也是隊(duì)列機(jī)制。

對(duì)，就是排隊(duì)。一個(gè)接著一個(gè)的處理，不能插隊(duì)。

RabbitMQ簡(jiǎn)介

AMQP，即Advanced Message Queuing Protocol，高級(jí)消息隊(duì)列協(xié)議，是應(yīng)用層協(xié)議的一個(gè)開(kāi)放標(biāo)準(zhǔn)，為面向消息的中間件設(shè)計(jì)。消息中間件主要用于組件之間的解耦，消息的發(fā)送者無(wú)需知道消息使用者的存在，反之亦然。 AMQP的主要特征是面向消息、隊(duì)列、路由（包括點(diǎn)對(duì)點(diǎn)和發(fā)布/訂閱）、可靠性、安全。 RabbitMQ是一個(gè)開(kāi)源的AMQP實(shí)現(xiàn)，服務(wù)器端用Erlang語(yǔ)言編寫(xiě)，支持多種客戶(hù)端，如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等，支持AJAX。用于在分布式系統(tǒng)中存儲(chǔ)轉(zhuǎn)發(fā)消息，在易用性、擴(kuò)展性、高可用性等方面表現(xiàn)不俗。 下面將重點(diǎn)介紹RabbitMQ中的一些基礎(chǔ)概念，了解了這些概念，是使用好RabbitMQ的基礎(chǔ)。

ConnectionFactory、Connection、Channel

ConnectionFactory、Connection、Channel都是RabbitMQ對(duì)外提供的API中最基本的對(duì)象。Connection是RabbitMQ的socket鏈接，它封裝了socket協(xié)議相關(guān)部分邏輯。ConnectionFactory為Connection的制造工廠。 Channel是我們與RabbitMQ打交道的最重要的一個(gè)接口，我們大部分的業(yè)務(wù)操作是在Channel這個(gè)接口中完成的，包括定義Queue、定義Exchange、綁定Queue與Exchange、發(fā)布消息等。

Queue

Queue（隊(duì)列）是RabbitMQ的內(nèi)部對(duì)象，用于存儲(chǔ)消息，用下圖表示。

RabbitMQ中的消息都只能存儲(chǔ)在Queue中，生產(chǎn)者（下圖中的P）生產(chǎn)消息并最終投遞到Queue中，消費(fèi)者（下圖中的C）可以從Queue中獲取消息并消費(fèi)。

多個(gè)消費(fèi)者可以訂閱同一個(gè)Queue，這時(shí)Queue中的消息會(huì)被平均分?jǐn)偨o多個(gè)消費(fèi)者進(jìn)行處理，而不是每個(gè)消費(fèi)者都收到所有的消息并處理。 

Message acknowledgment

在實(shí)際應(yīng)用中，可能會(huì)發(fā)生消費(fèi)者收到Queue中的消息，但沒(méi)有處理完成就宕機(jī)（或出現(xiàn)其他意外）的情況，這種情況下就可能會(huì)導(dǎo)致消息丟失。為了避免這種情況發(fā)生，我們可以要求消費(fèi)者在消費(fèi)完消息后發(fā)送一個(gè)回執(zhí)給RabbitMQ，RabbitMQ收到消息回執(zhí)（Message acknowledgment）后才將該消息從Queue中移除；如果RabbitMQ沒(méi)有收到回執(zhí)并檢測(cè)到消費(fèi)者的RabbitMQ連接斷開(kāi)，則RabbitMQ會(huì)將該消息發(fā)送給其他消費(fèi)者（如果存在多個(gè)消費(fèi)者）進(jìn)行處理。這里不存在timeout概念，一個(gè)消費(fèi)者處理消息時(shí)間再長(zhǎng)也不會(huì)導(dǎo)致該消息被發(fā)送給其他消費(fèi)者，除非它的RabbitMQ連接斷開(kāi)。 這里會(huì)產(chǎn)生另外一個(gè)問(wèn)題，如果我們的開(kāi)發(fā)人員在處理完業(yè)務(wù)邏輯后，忘記發(fā)送回執(zhí)給RabbitMQ，這將會(huì)導(dǎo)致嚴(yán)重的bug——Queue中堆積的消息會(huì)越來(lái)越多；消費(fèi)者重啟后會(huì)重復(fù)消費(fèi)這些消息并重復(fù)執(zhí)行業(yè)務(wù)邏輯…

另外pub message是沒(méi)有ack的。

Message durability

如果我們希望即使在RabbitMQ服務(wù)重啟的情況下，也不會(huì)丟失消息，我們可以將Queue與Message都設(shè)置為可持久化的（durable），這樣可以保證絕大部分情況下我們的RabbitMQ消息不會(huì)丟失。但依然解決不了小概率丟失事件的發(fā)生（比如RabbitMQ服務(wù)器已經(jīng)接收到生產(chǎn)者的消息，但還沒(méi)來(lái)得及持久化該消息時(shí)RabbitMQ服務(wù)器就斷電了），如果我們需要對(duì)這種小概率事件也要管理起來(lái)，那么我們要用到事務(wù)。由于這里僅為RabbitMQ的簡(jiǎn)單介紹，所以這里將不講解RabbitMQ相關(guān)的事務(wù)。

Prefetch count

前面我們講到如果有多個(gè)消費(fèi)者同時(shí)訂閱同一個(gè)Queue中的消息，Queue中的消息會(huì)被平攤給多個(gè)消費(fèi)者。這時(shí)如果每個(gè)消息的處理時(shí)間不同，就有可能會(huì)導(dǎo)致某些消費(fèi)者一直在忙，而另外一些消費(fèi)者很快就處理完手頭工作并一直空閑的情況。我們可以通過(guò)設(shè)置prefetchCount來(lái)限制Queue每次發(fā)送給每個(gè)消費(fèi)者的消息數(shù)，比如我們?cè)O(shè)置prefetchCount=1，則Queue每次給每個(gè)消費(fèi)者發(fā)送一條消息；消費(fèi)者處理完這條消息后Queue會(huì)再給該消費(fèi)者發(fā)送一條消息。

Exchange

在上一節(jié)我們看到生產(chǎn)者將消息投遞到Queue中，實(shí)際上這在RabbitMQ中這種事情永遠(yuǎn)都不會(huì)發(fā)生。實(shí)際的情況是，生產(chǎn)者將消息發(fā)送到Exchange（交換器，下圖中的X），由Exchange將消息路由到一個(gè)或多個(gè)Queue中（或者丟棄）。

Exchange是按照什么邏輯將消息路由到Queue的？這個(gè)將在Binding一節(jié)介紹。 RabbitMQ中的Exchange有四種類(lèi)型，不同的類(lèi)型有著不同的路由策略，這將在Exchange Types一節(jié)介紹。

routing key

生產(chǎn)者在將消息發(fā)送給Exchange的時(shí)候，一般會(huì)指定一個(gè)routing key，來(lái)指定這個(gè)消息的路由規(guī)則，而這個(gè)routing key需要與Exchange Type及binding key聯(lián)合使用才能最終生效。 在Exchange Type與binding key固定的情況下（在正常使用時(shí)一般這些內(nèi)容都是固定配置好的），我們的生產(chǎn)者就可以在發(fā)送消息給Exchange時(shí)，通過(guò)指定routing key來(lái)決定消息流向哪里。 RabbitMQ為routing key設(shè)定的長(zhǎng)度限制為255 bytes。

Binding

RabbitMQ中通過(guò)Binding將Exchange與Queue關(guān)聯(lián)起來(lái)，這樣RabbitMQ就知道如何正確地將消息路由到指定的Queue了。

Binding key

在綁定（Binding）Exchange與Queue的同時(shí)，一般會(huì)指定一個(gè)binding key；消費(fèi)者將消息發(fā)送給Exchange時(shí)，一般會(huì)指定一個(gè)routing key；當(dāng)binding key與routing key相匹配時(shí)，消息將會(huì)被路由到對(duì)應(yīng)的Queue中。這個(gè)將在Exchange Types章節(jié)會(huì)列舉實(shí)際的例子加以說(shuō)明。 在綁定多個(gè)Queue到同一個(gè)Exchange的時(shí)候，這些Binding允許使用相同的binding key。 binding key 并不是在所有情況下都生效，它依賴(lài)于Exchange Type，比如fanout類(lèi)型的Exchange就會(huì)無(wú)視binding key，而是將消息路由到所有綁定到該Exchange的Queue。

Exchange Types

RabbitMQ常用的Exchange Type有fanout、direct、topic、headers這四種（AMQP規(guī)范里還提到兩種Exchange Type，分別為system與自定義，這里不予以描述），下面分別進(jìn)行介紹。

fanout

fanout類(lèi)型的Exchange路由規(guī)則非常簡(jiǎn)單，它會(huì)把所有發(fā)送到該Exchange的消息路由到所有與它綁定的Queue中。

上圖中，生產(chǎn)者（P）發(fā)送到Exchange（X）的所有消息都會(huì)路由到圖中的兩個(gè)Queue，并最終被兩個(gè)消費(fèi)者（C1與C2）消費(fèi)。

direct

direct類(lèi)型的Exchange路由規(guī)則也很簡(jiǎn)單，它會(huì)把消息路由到那些binding key與routing key完全匹配的Queue中。

以上圖的配置為例，我們以routingKey=”error”發(fā)送消息到Exchange，則消息會(huì)路由到Queue1（amqp.gen-S9b…，這是由RabbitMQ自動(dòng)生成的Queue名稱(chēng)）和Queue2（amqp.gen-Agl…）；如果我們以routingKey=”info”或routingKey=”warning”來(lái)發(fā)送消息，則消息只會(huì)路由到Queue2。如果我們以其他routingKey發(fā)送消息，則消息不會(huì)路由到這兩個(gè)Queue中。

topic

前面講到direct類(lèi)型的Exchange路由規(guī)則是完全匹配binding key與routing key，但這種嚴(yán)格的匹配方式在很多情況下不能滿(mǎn)足實(shí)際業(yè)務(wù)需求。topic類(lèi)型的Exchange在匹配規(guī)則上進(jìn)行了擴(kuò)展，它與direct類(lèi)型的Exchage相似，也是將消息路由到binding key與routing key相匹配的Queue中，但這里的匹配規(guī)則有些不同，它約定：

• routing key為一個(gè)句點(diǎn)號(hào)“. ”分隔的字符串（我們將被句點(diǎn)號(hào)“. ”分隔開(kāi)的每一段獨(dú)立的字符串稱(chēng)為一個(gè)單詞），如“stock.usd.nyse”、“nyse.vmw”、“quick.orange.rabbit”
• binding key與routing key一樣也是句點(diǎn)號(hào)“. ”分隔的字符串
• binding key中可以存在兩種特殊字符“*”與“#”，用于做模糊匹配，其中“*”用于匹配一個(gè)單詞，“#”用于匹配多個(gè)單詞（可以是零個(gè)）

以上圖中的配置為例，routingKey=”quick.orange.rabbit”的消息會(huì)同時(shí)路由到Q1與Q2，routingKey=”lazy.orange.fox”的消息會(huì)路由到Q1與Q2，routingKey=”lazy.brown.fox”的消息會(huì)路由到Q2，routingKey=”lazy.pink.rabbit”的消息會(huì)路由到Q2（只會(huì)投遞給Q2一次，雖然這個(gè)routingKey與Q2的兩個(gè)bindingKey都匹配）；routingKey=”quick.brown.fox”、routingKey=”orange”、routingKey=”quick.orange.male.rabbit”的消息將會(huì)被丟棄，因?yàn)樗鼈儧](méi)有匹配任何bindingKey。

headers

headers類(lèi)型的Exchange不依賴(lài)于routing key與binding key的匹配規(guī)則來(lái)路由消息，而是根據(jù)發(fā)送的消息內(nèi)容中的headers屬性進(jìn)行匹配。 在綁定Queue與Exchange時(shí)指定一組鍵值對(duì)；當(dāng)消息發(fā)送到Exchange時(shí)，RabbitMQ會(huì)取到該消息的headers（也是一個(gè)鍵值對(duì)的形式），對(duì)比其中的鍵值對(duì)是否完全匹配Queue與Exchange綁定時(shí)指定的鍵值對(duì)；如果完全匹配則消息會(huì)路由到該Queue，否則不會(huì)路由到該Queue。 該類(lèi)型的Exchange沒(méi)有用到過(guò)（不過(guò)也應(yīng)該很有用武之地），所以不做介紹。

RPC

MQ本身是基于異步的消息處理，前面的示例中所有的生產(chǎn)者（P）將消息發(fā)送到RabbitMQ后不會(huì)知道消費(fèi)者（C）處理成功或者失敗（甚至連有沒(méi)有消費(fèi)者來(lái)處理這條消息都不知道）。 但實(shí)際的應(yīng)用場(chǎng)景中，我們很可能需要一些同步處理，需要同步等待服務(wù)端將我的消息處理完成后再進(jìn)行下一步處理。這相當(dāng)于RPC（Remote Procedure Call，遠(yuǎn)程過(guò)程調(diào)用）。在RabbitMQ中也支持RPC。

  RabbitMQ  中實(shí)現(xiàn)RPC 的機(jī)制是：

• 客戶(hù)端發(fā)送請(qǐng)求（消息）時(shí)，在消息的屬性（MessageProperties ，在AMQP 協(xié)議中定義了14中properties ，這些屬性會(huì)隨著消息一起發(fā)送）中設(shè)置兩個(gè)值replyTo （一個(gè)Queue 名稱(chēng)，用于告訴服務(wù)器處理完成后將通知我的消息發(fā)送到這個(gè)Queue 中）和correlationId （此次請(qǐng)求的標(biāo)識(shí)號(hào)，服務(wù)器處理完成后需要將此屬性返還，客戶(hù)端將根據(jù)這個(gè)id了解哪條請(qǐng)求被成功執(zhí)行了或執(zhí)行失?。?/li>
• 服務(wù)器端收到消息并處理
• 服務(wù)器端處理完消息后，將生成一條應(yīng)答消息到replyTo 指定的Queue ，同時(shí)帶上correlationId 屬性
• 客戶(hù)端之前已訂閱replyTo 指定的Queue ，從中收到服務(wù)器的應(yīng)答消息后，根據(jù)其中的correlationId 屬性分析哪條請(qǐng)求被執(zhí)行了，根據(jù)執(zhí)行結(jié)果進(jìn)行后續(xù)業(yè)務(wù)處理

總結(jié)

本文介紹了RabbitMQ 中個(gè)人認(rèn)為最重要的概念，充分利用RabbitMQ 提供的這些功能就可以處理我們絕大部分的異步業(yè)務(wù)了。

RabbitMQ 選型和對(duì)比

1.從社區(qū)活躍度

按照目前網(wǎng)絡(luò)上的資料，RabbitMQ 、activeM 、ZeroMQ 三者中，綜合來(lái)看，RabbitMQ 是首選。

2.持久化消息比較

ZeroMq 不支持，ActiveMq 和RabbitMq 都支持。持久化消息主要是指我們機(jī)器在不可抗力因素等情況下掛掉了，消息不會(huì)丟失的機(jī)制。

3.綜合技術(shù)實(shí)現(xiàn)

可靠性、靈活的路由、集群、事務(wù)、高可用的隊(duì)列、消息排序、問(wèn)題追蹤、可視化管理工具、插件系統(tǒng)等等。

RabbitMq / Kafka 最好，ActiveMq 次之，ZeroMq 最差。當(dāng)然ZeroMq 也可以做到，不過(guò)自己必須手動(dòng)寫(xiě)代碼實(shí)現(xiàn)，代碼量不小。尤其是可靠性中的：持久性、投遞確認(rèn)、發(fā)布者證實(shí)和高可用性。

4.高并發(fā)

毋庸置疑，RabbitMQ 最高，原因是它的實(shí)現(xiàn)語(yǔ)言是天生具備高并發(fā)高可用的erlang 語(yǔ)言。

5.比較關(guān)注的比較， RabbitMQ 和 Kafka

RabbitMq 比Kafka 成熟，在可用性上，穩(wěn)定性上，可靠性上，  RabbitMq  勝于  Kafka  （理論上）。

另外，Kafka 的定位主要在日志等方面， 因?yàn)?code>Kafka 設(shè)計(jì)的初衷就是處理日志的，可以看做是一個(gè)日志（消息）系統(tǒng)一個(gè)重要組件，針對(duì)性很強(qiáng)，所以 如果業(yè)務(wù)方面還是建議選擇 RabbitMq 。

還有就是，Kafka 的性能（吞吐量、TPS ）比RabbitMq 要高出來(lái)很多。

選型最后總結(jié)：

如果我們系統(tǒng)中已經(jīng)有選擇  Kafka  ，或者   RabbitMq  ，并且完全可以滿(mǎn)足現(xiàn)在的業(yè)務(wù)，建議就不用重復(fù)去增加和造輪子。

可以在  Kafka  和   RabbitMq  中選擇一個(gè)適合自己團(tuán)隊(duì)和業(yè)務(wù)的，這個(gè)才是最重要的。但是毋庸置疑現(xiàn)階段，綜合考慮沒(méi)有第三選擇。

版權(quán)所屬：SO JSON在線解析

原文地址：http://zijieyoumin.cn/blog/48.html

轉(zhuǎn)載時(shí)必須以鏈接形式注明原始出處及本聲明。

---

如果本文對(duì)你有幫助，那么請(qǐng)你贊助我，讓我更有激情的寫(xiě)下去，幫助更多的人。

￥我需要走的更遠(yuǎn)，點(diǎn)擊我 贊助。 如果還有疑問(wèn)，點(diǎn)擊我加群，為你提供最好的解答。