轉(zhuǎn)自：http://www.diggerplus.org/archives/3110
<h2>引言</h2>
<p>你是否遇到過兩個(gè)（多個(gè)）系統(tǒng)間需要通過定時(shí)任務(wù)來同步某些數(shù)據(jù)？你是否在為異構(gòu)系統(tǒng)的不同進(jìn)程間相互調(diào)用桅打、通訊的問題而苦惱豌习、掙扎？如果是银萍，那么恭喜你变勇，消息服務(wù)讓你可以很輕松地解決這些問題。<br />
消息服務(wù)擅長于解決多系統(tǒng)贴唇、異構(gòu)系統(tǒng)間的數(shù)據(jù)交換（消息通知/通訊）問題搀绣，你也可以把它用于系統(tǒng)間服務(wù)的相互調(diào)用（RPC）。本文將要介紹的RabbitMQ就是當(dāng)前最主流的消息<a title="中間件">中間件</a>之一戳气。</p>
<h2>RabbitMQ簡介</h2>
<p>AMQP链患，即Advanced Message Queuing Protocol，高級(jí)消息隊(duì)列協(xié)議瓶您，是應(yīng)用層協(xié)議的一個(gè)開放標(biāo)準(zhǔn)麻捻，為面向消息的<a title="中間件">中間件</a>設(shè)計(jì)。消息中間件主要用于組件之間的解耦呀袱，消息的發(fā)送者無需知道消息使用者的存在贸毕，反之亦然。<br />
AMQP的主要特征是面向消息夜赵、隊(duì)列明棍、路由（包括點(diǎn)對(duì)點(diǎn)和發(fā)布/訂閱）、可靠性寇僧、安全击蹲。<br />
RabbitMQ是一個(gè)開源的AMQP實(shí)現(xiàn)署拟，服務(wù)器端用Erlang語言編寫，支持多種客戶端歌豺，如：Python推穷、Ruby、.NET类咧、Java馒铃、JMS、C痕惋、PHP区宇、ActionScript、XMPP值戳、STOMP等议谷，支持AJAX。用于在分布式系統(tǒng)中存儲(chǔ)轉(zhuǎn)發(fā)消息堕虹，在易用性卧晓、擴(kuò)展性、高可用性等方面表現(xiàn)不俗赴捞。<br />
下面將重點(diǎn)介紹RabbitMQ中的一些基礎(chǔ)概念逼裆，了解了這些概念，是使用好RabbitMQ的基礎(chǔ)赦政。</p>
<h2>ConnectionFactory胜宇、Connection、Channel</h2>
<p>ConnectionFactory恢着、Connection桐愉、Channel都是RabbitMQ對(duì)外提供的API中最基本的對(duì)象。Connection是RabbitMQ的socket鏈接掰派，它封裝了socket協(xié)議相關(guān)部分邏輯仅财。ConnectionFactory為Connection的制造工廠。<br />
Channel是我們與RabbitMQ打交道的最重要的一個(gè)接口碗淌，我們大部分的業(yè)務(wù)操作是在Channel這個(gè)接口中完成的盏求，包括定義Queue、定義Exchange亿眠、綁定Queue與Exchange碎罚、發(fā)布消息等。</p>
<h2>Queue</h2>
<p>Queue（隊(duì)列）是RabbitMQ的內(nèi)部對(duì)象纳像，用于存儲(chǔ)消息荆烈，用下圖表示。<br />
<p>RabbitMQ中的消息都只能存儲(chǔ)在Queue中，生產(chǎn)者（下圖中的P）生產(chǎn)消息并最終投遞到Queue中憔购，消費(fèi)者（下圖中的C）可以從Queue中獲取消息并消費(fèi)宫峦。</p>
<p>
<p>多個(gè)消費(fèi)者可以訂閱同一個(gè)Queue，這時(shí)Queue中的消息會(huì)被平均分?jǐn)偨o多個(gè)消費(fèi)者進(jìn)行處理玫鸟，而不是每個(gè)消費(fèi)者都收到所有的消息并處理导绷。<br />
<h2>Message acknowledgment</h2>
<p>在實(shí)際應(yīng)用中，可能會(huì)發(fā)生消費(fèi)者收到Queue中的消息屎飘，但沒有處理完成就宕機(jī)（或出現(xiàn)其他意外）的情況妥曲，這種情況下就可能會(huì)導(dǎo)致消息丟失。為了避免這種情況發(fā)生钦购，我們可以要求消費(fèi)者在消費(fèi)完消息后發(fā)送一個(gè)回執(zhí)給RabbitMQ檐盟，RabbitMQ收到消息回執(zhí)（Message acknowledgment）后才將該消息從Queue中移除；如果RabbitMQ沒有收到回執(zhí)并檢測到消費(fèi)者的RabbitMQ連接斷開押桃，則RabbitMQ會(huì)將該消息發(fā)送給其他消費(fèi)者（如果存在多個(gè)消費(fèi)者）進(jìn)行處理葵萎。這里不存在timeout概念，一個(gè)消費(fèi)者處理消息時(shí)間再長也不會(huì)導(dǎo)致該消息被發(fā)送給其他消費(fèi)者唱凯，除非它的RabbitMQ連接斷開羡忘。<br />
這里會(huì)產(chǎn)生另外一個(gè)問題，如果我們的開發(fā)人員在處理完業(yè)務(wù)邏輯后波丰，忘記發(fā)送回執(zhí)給RabbitMQ，這將會(huì)導(dǎo)致嚴(yán)重的bug——Queue中堆積的消息會(huì)越來越多舶得；消費(fèi)者重啟后會(huì)重復(fù)消費(fèi)這些消息并重復(fù)執(zhí)行業(yè)務(wù)邏輯…</p>
<h2>Message durability</h2>
<p>如果我們希望即使在RabbitMQ服務(wù)重啟的情況下掰烟，也不會(huì)丟失消息，我們可以將Queue與Message都設(shè)置為可持久化的（durable）沐批，這樣可以保證絕大部分情況下我們的RabbitMQ消息不會(huì)丟失纫骑。但依然解決不了小概率丟失事件的發(fā)生（比如RabbitMQ服務(wù)器已經(jīng)接收到生產(chǎn)者的消息，但還沒來得及持久化該消息時(shí)RabbitMQ服務(wù)器就斷電了）九孩，如果我們需要對(duì)這種小概率事件也要管理起來先馆，那么我們要用到事務(wù)。由于這里僅為RabbitMQ的簡單介紹躺彬，所以這里將不講解RabbitMQ相關(guān)的事務(wù)煤墙。</p>
<h2>Prefetch count</h2>
<p>前面我們講到如果有多個(gè)消費(fèi)者同時(shí)訂閱同一個(gè)Queue中的消息，Queue中的消息會(huì)被平攤給多個(gè)消費(fèi)者宪拥。這時(shí)如果每個(gè)消息的處理時(shí)間不同仿野，就有可能會(huì)導(dǎo)致某些消費(fèi)者一直在忙，而另外一些消費(fèi)者很快就處理完手頭工作并一直空閑的情況她君。我們可以通過設(shè)置prefetchCount來限制Queue每次發(fā)送給每個(gè)消費(fèi)者的消息數(shù)脚作，比如我們?cè)O(shè)置prefetchCount=1，則Queue每次給每個(gè)消費(fèi)者發(fā)送一條消息；消費(fèi)者處理完這條消息后Queue會(huì)再給該消費(fèi)者發(fā)送一條消息球涛。</p>
<p>
<h2>Exchange</h2>
<p>在上一節(jié)我們看到生產(chǎn)者將消息投遞到Queue中劣针，實(shí)際上這在RabbitMQ中這種事情永遠(yuǎn)都不會(huì)發(fā)生。實(shí)際的情況是亿扁，生產(chǎn)者將消息發(fā)送到Exchange（交換器捺典，下圖中的X），由Exchange將消息路由到一個(gè)或多個(gè)Queue中（或者丟棄）魏烫。</p>
<p>
<p>Exchange是按照什么邏輯將消息路由到Queue的辣苏？這個(gè)將在Binding一節(jié)介紹。<br />
RabbitMQ中的Exchange有四種類型哄褒，不同的類型有著不同的路由策略稀蟋，這將在Exchange Types一節(jié)介紹。</p>
<h2>routing key</h2>
<p>生產(chǎn)者在將消息發(fā)送給Exchange的時(shí)候呐赡，一般會(huì)指定一個(gè)routing key退客，來指定這個(gè)消息的路由規(guī)則，而這個(gè)routing key需要與Exchange Type及binding key聯(lián)合使用才能最終生效链嘀。<br />
在Exchange Type與binding key固定的情況下（在正常使用時(shí)一般這些內(nèi)容都是固定配置好的）萌狂，我們的生產(chǎn)者就可以在發(fā)送消息給Exchange時(shí)，通過指定routing key來決定消息流向哪里怀泊。<br />
RabbitMQ為routing key設(shè)定的長度限制為255 bytes茫藏。</p>
<h2>Binding</h2>
<p>RabbitMQ中通過Binding將Exchange與Queue關(guān)聯(lián)起來，這樣RabbitMQ就知道如何正確地將消息路由到指定的Queue了霹琼。<br />
<h2>Binding key</h2>
<p>在綁定（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í)際的例子加以說明挟伙。<br />
在綁定多個(gè)Queue到同一個(gè)Exchange的時(shí)候，這些Binding允許使用相同的binding key模孩。<br />
binding key 并不是在所有情況下都生效尖阔，它依賴于Exchange Type，比如fanout類型的Exchange就會(huì)無視binding key榨咐，而是將消息路由到所有綁定到該Exchange的Queue诺祸。</p>
<h2>Exchange Types</h2>
<p>RabbitMQ常用的Exchange Type有fanout、direct祭芦、topic筷笨、headers這四種（AMQP規(guī)范里還提到兩種Exchange Type，分別為system與自定義，這里不予以描述）胃夏，下面分別進(jìn)行介紹轴或。</p>
<h2>fanout</h2>
<p>fanout類型的Exchange路由規(guī)則非常簡單，它會(huì)把所有發(fā)送到該Exchange的消息路由到所有與它綁定的Queue中仰禀。<br />
<p>上圖中照雁，生產(chǎn)者（P）發(fā)送到Exchange（X）的所有消息都會(huì)路由到圖中的兩個(gè)Queue，并最終被兩個(gè)消費(fèi)者（C1與C2）消費(fèi)答恶。</p>
<h2>direct</h2>
<p>direct類型的Exchange路由規(guī)則也很簡單饺蚊，它會(huì)把消息路由到那些binding key與routing key完全匹配的Queue中。<br />
<p>以上圖的配置為例悬嗓，我們以routingKey=”error”發(fā)送消息到Exchange污呼，則消息會(huì)路由到Queue1（amqp.gen-S9b…，這是由RabbitMQ自動(dòng)生成的Queue名稱）和Queue2（amqp.gen-Agl…）包竹；如果我們以routingKey=”info”或routingKey=”warning”來發(fā)送消息燕酷，則消息只會(huì)路由到Queue2。如果我們以其他routingKey發(fā)送消息周瞎，則消息不會(huì)路由到這兩個(gè)Queue中苗缩。</p>
<h2>topic</h2>
<p>前面講到direct類型的Exchange路由規(guī)則是完全匹配binding key與routing key，但這種嚴(yán)格的匹配方式在很多情況下不能滿足實(shí)際業(yè)務(wù)需求声诸。topic類型的Exchange在匹配規(guī)則上進(jìn)行了擴(kuò)展酱讶，它與direct類型的Exchage相似，也是將消息路由到binding key與routing key相匹配的Queue中彼乌，但這里的匹配規(guī)則有些不同泻肯，它約定：</p>
<ul>
<li>routing key為一個(gè)句點(diǎn)號(hào)“. ”分隔的字符串（我們將被句點(diǎn)號(hào)“. ”分隔開的每一段獨(dú)立的字符串稱為一個(gè)單詞），如“stock.usd.nyse”囤攀、“nyse.vmw”软免、“quick.orange.rabbit”</li>
<li>binding key與routing key一樣也是句點(diǎn)號(hào)“. ”分隔的字符串</li>
<li>binding key中可以存在兩種特殊字符“”與“#”宫纬，用于做模糊匹配焚挠，其中“”用于匹配一個(gè)單詞，“#”用于匹配多個(gè)單詞（可以是零個(gè)）</li>
</ul>
<p>
<p>以上圖中的配置為例漓骚，routingKey=”quick.orange.rabbit”的消息會(huì)同時(shí)路由到Q1與Q2蝌衔，routingKey=”lazy.orange.fox”的消息會(huì)路由到Q1，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)樗鼈儧]有匹配任何bindingKey。</p>
<h2>headers</h2>
<p>headers類型的Exchange不依賴于routing key與binding key的匹配規(guī)則來路由消息斥废，而是根據(jù)發(fā)送的消息內(nèi)容中的headers屬性進(jìn)行匹配椒楣。<br />
在綁定Queue與Exchange時(shí)指定一組鍵值對(duì)；當(dāng)消息發(fā)送到Exchange時(shí)牡肉，RabbitMQ會(huì)取到該消息的headers（也是一個(gè)鍵值對(duì)的形式）捧灰，對(duì)比其中的鍵值對(duì)是否完全匹配Queue與Exchange綁定時(shí)指定的鍵值對(duì)；如果完全匹配則消息會(huì)路由到該Queue统锤，否則不會(huì)路由到該Queue毛俏。<br />
該類型的Exchange沒有用到過（不過也應(yīng)該很有用武之地），所以不做介紹饲窿。</p>
<h2>RPC</h2>
<p>MQ本身是基于異步的消息處理煌寇，前面的示例中所有的生產(chǎn)者（P）將消息發(fā)送到RabbitMQ后不會(huì)知道消費(fèi)者（C）處理成功或者失敗（甚至連有沒有消費(fèi)者來處理這條消息都不知道）免绿。<br />
但實(shí)際的應(yīng)用場景中唧席，我們很可能需要一些同步處理，需要同步等待服務(wù)端將我的消息處理完成后再進(jìn)行下一步處理嘲驾。這相當(dāng)于RPC（Remote Procedure Call淌哟，遠(yuǎn)程過程調(diào)用）。在RabbitMQ中也支持RPC辽故。<br />
RabbitMQ中實(shí)現(xiàn)RPC的機(jī)制是：</p>
<ul>
<li>客戶端發(fā)送請(qǐng)求（消息）時(shí)徒仓，在消息的屬性（MessageProperties，在AMQP協(xié)議中定義了14中properties誊垢，這些屬性會(huì)隨著消息一起發(fā)送）中設(shè)置兩個(gè)值replyTo（一個(gè)Queue名稱掉弛，用于告訴服務(wù)器處理完成后將通知我的消息發(fā)送到這個(gè)Queue中）和correlationId（此次請(qǐng)求的標(biāo)識(shí)號(hào)，服務(wù)器處理完成后需要將此屬性返還喂走，客戶端將根據(jù)這個(gè)id了解哪條請(qǐng)求被成功執(zhí)行了或執(zhí)行失斞甓觥）
</li>
<li>服務(wù)器端收到消息并處理</li>
<li>服務(wù)器端處理完消息后，將生成一條應(yīng)答消息到replyTo指定的Queue芋肠，同時(shí)帶上correlationId屬性</li>
<li>客戶端之前已訂閱replyTo指定的Queue乎芳，從中收到服務(wù)器的應(yīng)答消息后，根據(jù)其中的correlationId屬性分析哪條請(qǐng)求被執(zhí)行了帖池，根據(jù)執(zhí)行結(jié)果進(jìn)行后續(xù)業(yè)務(wù)處理</li>
</ul>
<h2>總結(jié)</h2>
本文介紹了RabbitMQ中個(gè)人認(rèn)為最重要的概念奈惑，充分利用RabbitMQ提供的這些功能就可以處理我們絕大部分的異步業(yè)務(wù)了。<br />
本篇的基本概念可能很難理解并消化睡汹，結(jié)合實(shí)際的應(yīng)用代碼應(yīng)該會(huì)比較容易吸收肴甸。所以接下來要寫的文章例中會(huì)包含實(shí)際的業(yè)務(wù)應(yīng)用場景分析，為什么使用RabbitMQ來實(shí)現(xiàn)囚巴，如何用RabbitMQ來實(shí)現(xiàn)原在。</p>
