MQ選型之RabbitMQ

RabbitMQ是部署最普遍的開源消息代理。【官方原話】

前言：

    MQ 是什麼？隊列是什麼，MQ 咱們能夠理解爲消息隊列(message queue)，隊列咱們能夠理解爲管道。以管道的方式作消息傳遞。　　　　　　　　

　　RabbitMQ在全球範圍內在小型初創公司和大型企業中進行了超過35,000次RabbitMQ生產部署，是最受歡迎的開源消息代理。RabbitMQ輕量級，易於在內部和雲中部署。它支持多種消息傳遞協議。RabbitMQ能夠部署在分佈式和聯合配置中，以知足高規模，高可用性要求。RabbitMQ可在許多操做系統和雲環境中運行，並爲大多數流行語言提供各類開發人員工具。

 

概念：

　　AMQP協議： http://www.rabbitmq.com/amqp-0-9-1-quickref.html

 

安裝：

　　這個很少說，請見： http://www.rabbitmq.com/download.html 

 

 

場景：

    1.其實咱們在雙11的時候，當咱們凌晨大量的秒殺和搶購商品，而後去結算的時候，就會發現，界面會提醒咱們，讓咱們稍等，以及一些友好的圖片文字提醒。而不是像前幾年的時代，動不動就頁面卡死，報錯等來呈現給用戶。

    在這業務場景中，咱們就能夠採用隊列的機制來處理，由於同時結算就只能達到這麼多。

    2.在咱們平時的超市中購物也是同樣，當咱們在結算的時候，並不會一窩蜂同樣涌入收銀臺，而是排隊結算。這也是隊列機制。

對，就是排隊。一個接着一個的處理，不能插隊。

RabbitMQ簡介

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

ConnectionFactory、Connection、Channel

ConnectionFactory、Connection、Channel都是RabbitMQ對外提供的API中最基本的對象。Connection是RabbitMQ的socket連接，它封裝了socket協議相關部分邏輯。ConnectionFactory爲Connection的製造工廠。 Channel是咱們與RabbitMQ打交道的最重要的一個接口，咱們大部分的業務操做是在Channel這個接口中完成的，包括定義Queue、定義Exchange、綁定Queue與Exchange、發佈消息等。

Queue

Queue（隊列）是RabbitMQ的內部對象，用於存儲消息，用下圖表示。

RabbitMQ中的消息都只能存儲在Queue中，生產者（下圖中的P）生產消息並最終投遞到Queue中，消費者（下圖中的C）能夠從Queue中獲取消息並消費。

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

Message acknowledgment

在實際應用中，可能會發生消費者收到Queue中的消息，但沒有處理完成就宕機（或出現其餘意外）的狀況，這種狀況下就可能會致使消息丟失。爲了不這種狀況發生，咱們能夠要求消費者在消費完消息後發送一個回執給RabbitMQ，RabbitMQ收到消息回執（Message acknowledgment）後纔將該消息從Queue中移除；若是RabbitMQ沒有收到回執並檢測到消費者的RabbitMQ鏈接斷開，則RabbitMQ會將該消息發送給其餘消費者（若是存在多個消費者）進行處理。這裏不存在timeout概念，一個消費者處理消息時間再長也不會致使該消息被髮送給其餘消費者，除非它的RabbitMQ鏈接斷開。 這裏會產生另一個問題，若是咱們的開發人員在處理完業務邏輯後，忘記發送回執給RabbitMQ，這將會致使嚴重的bug——Queue中堆積的消息會愈來愈多；消費者重啓後會重複消費這些消息並重復執行業務邏輯…

另外pub message是沒有ack的。

Message durability

若是咱們但願即便在RabbitMQ服務重啓的狀況下，也不會丟失消息，咱們能夠將Queue與Message都設置爲可持久化的（durable），這樣能夠保證絕大部分狀況下咱們的RabbitMQ消息不會丟失。但依然解決不了小几率丟失事件的發生（好比RabbitMQ服務器已經接收到生產者的消息，但還沒來得及持久化該消息時RabbitMQ服務器就斷電了），若是咱們須要對這種小几率事件也要管理起來，那麼咱們要用到事務。因爲這裏僅爲RabbitMQ的簡單介紹，因此這裏將不講解RabbitMQ相關的事務。

Prefetch count

前面咱們講到若是有多個消費者同時訂閱同一個Queue中的消息，Queue中的消息會被平攤給多個消費者。這時若是每一個消息的處理時間不一樣，就有可能會致使某些消費者一直在忙，而另一些消費者很快就處理完手頭工做並一直空閒的狀況。咱們能夠經過設置prefetchCount來限制Queue每次發送給每一個消費者的消息數，好比咱們設置prefetchCount=1，則Queue每次給每一個消費者發送一條消息；消費者處理完這條消息後Queue會再給該消費者發送一條消息。

Exchange

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

Exchange是按照什麼邏輯將消息路由到Queue的？這個將在Binding一節介紹。 RabbitMQ中的Exchange有四種類型，不一樣的類型有着不一樣的路由策略，這將在Exchange Types一節介紹。

routing key

生產者在將消息發送給Exchange的時候，通常會指定一個routing key，來指定這個消息的路由規則，而這個routing key須要與Exchange Type及binding key聯合使用才能最終生效。 在Exchange Type與binding key固定的狀況下（在正常使用時通常這些內容都是固定配置好的），咱們的生產者就能夠在發送消息給Exchange時，經過指定routing key來決定消息流向哪裏。 RabbitMQ爲routing key設定的長度限制爲255 bytes。

Binding

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

Binding key

在綁定（Binding）Exchange與Queue的同時，通常會指定一個binding key；消費者將消息發送給Exchange時，通常會指定一個routing key；當binding key與routing key相匹配時，消息將會被路由到對應的Queue中。這個將在Exchange Types章節會列舉實際的例子加以說明。 在綁定多個Queue到同一個Exchange的時候，這些Binding容許使用相同的binding key。 binding key 並非在全部狀況下都生效，它依賴於Exchange Type，好比fanout類型的Exchange就會無視binding key，而是將消息路由到全部綁定到該Exchange的Queue。

Exchange Types

RabbitMQ經常使用的Exchange Type有fanout、direct、topic、headers這四種（AMQP規範裏還提到兩種Exchange Type，分別爲system與自定義，這裏不予以描述），下面分別進行介紹。

fanout

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

上圖中，生產者（P）發送到Exchange（X）的全部消息都會路由到圖中的兩個Queue，並最終被兩個消費者（C1與C2）消費。

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與Q2，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 屬性分析哪條請求被執行了，根據執行結果進行後續業務處理

總結

　　本文介紹了RabbitMQ 中我的認爲最重要的概念，充分利用RabbitMQ 提供的這些功能就能夠處理咱們絕大部分的異步業務了。

　　快速上手Demo:  http://www.rabbitmq.com/getstarted.html

 

 

RabbitMQ 選型和對比

1.從社區活躍度

按照目前網絡上的資料，RabbitMQ 、activeM 、ZeroMQ 三者中，綜合來看，RabbitMQ 是首選。 

2.持久化消息比較

ZeroMq 不支持，ActiveMq 和RabbitMq 都支持。持久化消息主要是指咱們機器在不可抗力因素等狀況下掛掉了，消息不會丟失的機制。

3.綜合技術實現

可靠性、靈活的路由、集羣、事務、高可用的隊列、消息排序、問題追蹤、可視化管理工具、插件系統等等。

RabbitMq / Kafka 最好，ActiveMq 次之，ZeroMq 最差。固然ZeroMq 也能夠作到，不過本身必須手動寫代碼實現，代碼量不小。尤爲是可靠性中的：持久性、投遞確認、發佈者證明和高可用性。

4.高併發

毋庸置疑，RabbitMQ 最高，緣由是它的實現語言是天生具有高併發高可用的erlang 語言。

5.比較關注的比較， RabbitMQ 和 Kafka

RabbitMq 比Kafka 成熟，在可用性上，穩定性上，可靠性上，  RabbitMq  勝於  Kafka  （理論上）。

另外，Kafka 的定位主要在日誌等方面， 由於Kafka 設計的初衷就是處理日誌的，能夠看作是一個日誌（消息）系統一個重要組件，針對性很強，因此 若是業務方面仍是建議選擇 RabbitMq 。

還有就是，Kafka 的性能（吞吐量、TPS ）比RabbitMq 要高出來不少。

選型最後總結：

若是咱們系統中已經有選擇  Kafka  ，或者   RabbitMq  ，而且徹底能夠知足如今的業務，建議就不用重複去增長和造輪子。

能夠在  Kafka  和   RabbitMq  中選擇一個適合本身團隊和業務的，這個纔是最重要的。可是毋庸置疑現階段，綜合考慮沒有第三選擇。