柯南君：看大數據時代下的IT架構（2）消息隊列之RabbitMQ-基礎概念詳細介紹

1、基礎概念詳細介紹

一、引言

你是否遇到過兩個（多個）系統間須要經過定時任務來同步某些數據？你是否在爲異構系統的不一樣進程間相互調用、通信的問題而苦惱、掙扎？若是是，那麼恭喜你，消息服務讓你能夠很輕鬆地解決這些問題。
消息服務擅長於解決多系統、異構系統間的數據交換（消息通知/通信）問題，你也能夠把它用於系統間服務的相互調用（RPC）。本文將要介紹的RabbitMQ就是當前最主流的消息中間件之一。 

二、RabbitMQ簡介

RabbitMQ是流行的開源消息隊列系統，用erlang語言開發。RabbitMQ是AMQP（高級消息隊列協議）的標準實現。若是不熟悉AMQP，直接看RabbitMQ的文檔會比較困難。首先講一下AMQP

AMQP，即Advanced Message Queuing Protocol，高級消息隊列協議，是應用層協議的一個開放標準，爲面向消息的中間件設計。消息中間件主要用於組件之間的解耦，消息的發送者無需知道消息使用者的存在，反之亦然。
AMQP的主要特徵是面向消息、隊列、路由（包括點對點和發佈/訂閱）、可靠性、安全。
RabbitMQ是一個開源的AMQP實現，服務器端用Erlang語言編寫，支持多種客戶端，如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等，支持AJAX。用於在分佈式系統中存儲轉發消息，在易用性、擴展性、高可用性等方面表現不俗。
下面將重點介紹RabbitMQ中的一些基礎概念，瞭解了這些概念，是使用好RabbitMQ的基礎。

三、基本概念

1）RabbitMQ 結構圖以下：

2）重點介紹一些比較重要基礎概念

① Quque：（隊列）

Quque（隊列）是RabbitMQ的內部對象，用於存儲信息，有下圖(1-3-2-1)表示

(1-3-2-1)

RabbitMQ中的信息只能存儲在Quque中，生產者（下圖中的P）生產者消息並最終投遞到Quque中，消費者（如圖中1-3-2-2的C）能夠從Quque中獲取消息並消費。

(1-3-2-2)

多個消費者能夠訂閱同一個Quque，這時Quque中的消息會被平均分攤給多個消費者進行處理，而不是每一個消費者都收到全部消息並處理。

② Message acknowlegment：（消息回執）

在實際應用中，可能會發生消費者收到Quque中的消息，但沒有處理完成就宕機的狀況，這種狀況下，就可能致使信息丟失，爲了不這種狀況發生，咱們能夠要求消費者在消費完消息後發送一個回執給RabbitMQ,RabbitMQ收到消息回執（Message acknowledge）後，纔將該消息從Quque中移除。若是RabbitMQ沒有收到回執，並檢測到消費者的RabbitMQ連接斷開，則RabbitMQ 會將該消息發送給其餘消費者（若是存在多個消費者的狀況下）進行處理，這裏不存在timeout的概念，一個消費者處理消費時間無論多麼長也不會致使該消息被髮送給其餘消費者，除非它的RabbitMQ鏈接斷開；

注意：這裏會產生一個問題，若是開發人員再處理業務完成邏輯後，忘記發送回執給RabbitMQ，這將會致使嚴重的bug---Quque中堆積的消息會愈來愈多；消費者重啓會重複消費這些消息並重復執行業務邏輯。

③Message durability：（消息持久化）

若是咱們但願即便在RabbitMQ在重啓的狀況下，也不會丟失消息，那麼咱們將Quque與Message都設置成可持久化的（durability），這樣就能夠保證絕大部分狀況下咱們的RabbitMQ消息不會丟失。但依然解決不了小几率的丟失事件的發生(好比 RabbitMQ服務器已經接收到生產者的消息，可是，尚未來的及持久化該消息時，RabbitMQ服務器就斷電了或者宕機了)，若是咱們須要對這種小几率事件也要管理起來的話，那麼咱們須要用到事務。

④ Prefetch count （預取數目）

前面咱們提到了若是有多個消費者同時訂閱同一個Quque中的消息，Quque中的消息會被平攤給多個消費者。這時若是每一個消息的處理時間不一樣，就有可能致使某些消費者一直很忙，而另外一些消費者很快處理完手頭上工做，並一直空閒的狀況下。咱們能夠經過設置prefetch count=1，則Quque每次給每一個消費者發送一條消息；消費者處理完這條消息後Quque會再給消費者發送一條消息。

⑤ Exchange （交換器）

上一節咱們看到生產者將消息投遞到Quque中，實際上這在RabbitMQ是不可能發生的，實際上的狀況是，生產者將消息發送到Exchange（交換器，下圖中X），Exchange將消息路由到一個或者多個Quque中或者丟棄。

Exchange是按照什麼邏輯將消息路由到Quque的？這將在Binding一節詳談。

RabbitMQ中的Exchange有四種類型，不一樣的類型有着不一樣的路由策略，這將在Exchange Types一節詳談

⑥ routing key（路由key）

生產者在將消息發送給Exchange的時候，通常會指定一個routing key，來指定這個路由規則，而這個routing key須要與 Exchange Type 與binding key 聯合使用才能最終生效。

在Exchange Tpye 與binding key 固定的狀況下(在正常使用狀況下，這些內容都是配置好的)，咱們的生產者就能夠在發送消息給Exchange的時候，經過指定routing key 來指定消息流的流向哪裏。

⑦ Binding (綁定)

RabbitMQ 中經過Binding 將Exchange 與Quque關聯起來，這樣RabbitMQ就知道如何正確地將消息路由到指定的Quque了

⑧ Exchange Type （更換類型）

RabbitMQ經常使用的Exchange Tpye 有fanout、direct、top、headers這四種

 

⑨ fanout （分列）

fanout類型的Exchange路由規則很是簡單，它會把全部發送到該Exchange的消息路由到全部與它綁定的Queue中。

⑩　direct （重定向）

direct類型的Exchange路由規則也很簡單，它會把消息路由到那些binding key與routing key徹底匹配的Queue中。

以上圖的配置爲例，咱們以routingKey=」error」發送消息到Exchange，則消息會路由到Queue1（amqp.gen-S9b…，這是由RabbitMQ自動生成的Queue名稱）和Queue2（amqp.gen-Agl…）；若是咱們以routingKey=」info」或routingKey=」warning」來發送消息，則消息只會路由到Queue2。若是咱們以其餘routingKey發送消息，則消息不會路由到這兩個Queue中。

⑪　topic（主題）

前面講到direct類型的Exchange路由規則是徹底匹配binding key與routing key，但這種嚴格的匹配方式在不少狀況下不能知足實際業務需求。topic類型的Exchange在匹配規則上進行了擴展，它與direct類型的Exchage類似，也是將消息路由到binding key與routing key相匹配的Queue中，但這裏的匹配規則有些不一樣，它約定：

• routing key爲一個句點號「. 」分隔的字符串（咱們將被句點號「. 」分隔開的每一段獨立的字符串稱爲一個單詞），如「stock.usd.nyse」、「nyse.vmw」、「quick.orange.rabbit」
• binding key與routing key同樣也是句點號「. 」分隔的字符串
• binding key中能夠存在兩種特殊字符「*」與「#」，用於作模糊匹配，其中「*」用於匹配一個單詞，「#」用於匹配多個單詞（能夠是零個）】

以上圖中的配置爲例，routingKey=」quick.orange.rabbit」的消息會同時路由到Q1與Q2，routingKey=」lazy.orange.fox」的消息會路由到Q1，routingKey=」lazy.brown.fox」的消息會路由到Q2，routingKey=」lazy.pink.rabbit」的消息會路由到Q2（只會投遞給Q2一次，雖然這個routingKey與Q2的兩個bindingKey都匹配）；routingKey=」quick.brown.fox」、routingKey=」orange」、routingKey=」quick.orange.male.rabbit」的消息將會被丟棄，由於它們沒有匹配任何bindingKey。

⑫　headers

headers類型的Exchange不依賴於routing key與binding key的匹配規則來路由消息，而是根據發送的消息內容中的headers屬性進行匹配。
在綁定Queue與Exchange時指定一組鍵值對；當消息發送到Exchange時，RabbitMQ會取到該消息的headers（也是一個鍵值對的形式），對比其中的鍵值對是否徹底匹配Queue與Exchange綁定時指定的鍵值對；若是徹底匹配則消息會路由到該Queue，不然不會路由到該Queue。
該類型的Exchange沒有用到過（不過也應該頗有用武之地），因此不作介紹。

⑬　RPC（遠程過程調用）

MQ自己是基於異步的消息處理，前面的示例中全部的生產者（P）將消息發送到RabbitMQ後不會知道消費者（C）處理成功或者失敗（甚至連有沒有消費者來處理這條消息都不知道）。
但實際的應用場景中，咱們極可能須要一些同步處理，須要同步等待服務端將個人消息處理完成後再進行下一步處理。這至關於RPC（Remote Procedure Call，遠程過程調用）。在RabbitMQ中也支持RPC。

 

RabbitMQ中實現RPC的機制是：

• 客戶端發送請求（消息）時，在消息的屬性（MessageProperties，在AMQP協議中定義了14中properties，這些屬性會隨着消息一塊兒發送）中設置兩個值replyTo（一個Queue名稱，用於告訴服務器處理完成後將通知個人消息發送到這個Queue中）和correlationId（這次請求的標識號，服務器處理完成後須要將此屬性返還，客戶端將根據這個id瞭解哪條請求被成功執行了或執行失敗）
• 服務器端收到消息並處理
• 服務器端處理完消息後，將生成一條應答消息到replyTo指定的Queue，同時帶上correlationId屬性
• 客戶端以前已訂閱replyTo指定的Queue，從中收到服務器的應答消息後，根據其中的correlationId屬性分析哪條請求被執行了，根據執行結果進行後續業務處理

2、MQ特色

3、使用場景

4、含義

5、安裝

http://blog.csdn.net/sun305355024sun/article/details/41918315

6、客戶端

7、服務端