RabbitMQ——第一篇：RabbitMQ介紹

1.關于RabbitMQ##

RabbitMQ是一個開源的消息代理和隊列服務器，用來通過普通協(xié)議在完全不同的應用之間共享數(shù)據(jù)，或者簡單的將作業(yè)排隊以便讓分布式服務器進行處理。
下列內(nèi)容轉自：連接Kiven中間件rabbitMQ介紹，向作者致敬。因為后續(xù)需要介紹關于IOS端RabbitMQ做鋪墊，原文內(nèi)容稍作改動，望請見諒！

  • AMQP，即Advanced Message Queuing Protocol，高級消息隊列協(xié)議，是應用層協(xié)議的一個開放標準，為面向消息的中間件設計。消息中間件主要用于組件之間的解耦，消息的發(fā)送者無需知道消息使用者的存在，反之亦然。
  • AMQP的主要特征是面向消息、隊列、路由（包括點對點和發(fā)布/訂閱）、可靠性、安全。
  • RabbitMQ是一個開源的AMQP實現(xiàn)，服務器端用Erlang語言編寫，支持多種客戶端，如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等，支持AJAX,最重要的是也支持OC和swift。用于在分布式系統(tǒng)中存儲轉發(fā)消息，在易用性、擴展性、高可用性等方面表現(xiàn)不俗。

2.RabbitMQ與messaging in general 使用的術語##

producer####

producer表示消息的生產(chǎn)者，用來創(chuàng)建消息，然后發(fā)布到代理服務器（RabbitMQ）。消息包括有效載荷和標簽，

producer：生產(chǎn)者

consumer####

consumer是消息的接受者，比如各種的客戶端。

queue####

queue就像一個RabbitMQ的信箱，是AMQP消息通信的基礎模塊。

  • queue為消息提供處所，消息在此等待消費。

  • queue對負載均衡來說，隊列是絕佳方案。只需要附加一堆消費者，并讓RabbitMQ以循環(huán)的方式均勻地分配發(fā)來的消息。

  • queue只受主機內(nèi)存和磁盤的限制，它的的本質(zhì)是一個巨大的消息緩沖區(qū)。producer可以向queue發(fā)送消息，consumers也可以從queue接收消息。

  • queue是RabbitMQ的內(nèi)部對象，用于存儲消息，用下圖表示。

    queue：隊列

  • RabbitMQ中的消息都只能存儲在Queue中，生產(chǎn)者生產(chǎn)消息并最終投遞到隊列中，消費者可以從隊列中獲取消息并消費。

    一個生產(chǎn)者對多了消費者

  • 多個消費者可以訂閱同一個Queue，這時Queue中的消息會被平均分攤給多個消費者進行處理，而不是每個消費者都收到所有的消息并處理。

    一個生產(chǎn)者對多了消費者

ConnectionFactory、Connection、Channel####

ConnectionFactory、Connection、Channel都是RabbitMQ對外提供的API中最基本的對象。

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

Message acknowledgment####

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

Exchange####

實際的情況是，生產(chǎn)者將消息發(fā)送到Exchange（交換機，下圖中的X），由Exchange將消息路由到一個或多個Queue中（或者丟棄）。

routing key####

生產(chǎn)者在將消息發(fā)送給Exchange的時候，一般會指定一個routing key（當然也可以不指定），來指定這個消息的路由規(guī)則，而這個routing key需要與Exchange Type及binding key聯(lián)合使用才能最終生效。

在Exchange Type與binding key固定的情況下，我們的生產(chǎn)者就可以在發(fā)送消息給Exchange時，通過指定routing key來決定消息流向哪里。RabbitMQ為routing key設定的長度限制為255 bytes。

Binding####

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

Binding key####

在綁定（Binding）Exchange與Queue的同時，一般會指定一個binding key；消費者將消息發(fā)送給Exchange時，一般會指定一個routing key；當binding key與routing key相匹配時，消息將會被路由到對應的Queue中。
在綁定多個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規(guī)范里還提到兩種Exchange Type，分別為system與自定義，這里不予以描述），下面分別進行介紹。

direct####

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

RabbitMQ基礎概念詳細介紹
以上圖的配置為例，我們以routingKey=”error”發(fā)送消息到Exchange，則消息會路由到Queue1（amqp.gen-S9b…，這是由RabbitMQ自動生成的Queue名稱）和Queue2（amqp.gen-Agl…）；如果我們以routingKey=”info”或routingKey=”warning”來發(fā)送消息，則消息只會路由到Queue2。如果我們以其他routingKey發(fā)送消息，則消息不會路由到這兩個Queue中。

topic####

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

  • routing key為一個句點號“. ”分隔的字符串（我們將被句點號“. ”分隔開的每一段獨立的字符串稱為一個單詞），如“stock.usd.nyse”、“nyse.vmw”、“quick.orange.rabbit”
  • binding key與routing key一樣也是句點號“. ”分隔的字符串
  • binding key中可以存在兩種特殊字符“*”與“#”，用于做模糊匹配，其中“*”用于匹配一個單詞，“#”用于匹配多個單詞（可以是零個）

    RabbitMQ基礎概念詳細介紹:
    以上圖中的配置為例，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的匹配規(guī)則來路由消息，而是根據(jù)發(fā)送的消息內(nèi)容中的headers屬性進行匹配。
在綁定Queue與Exchange時指定一組鍵值對；當消息發(fā)送到Exchange時，RabbitMQ會取到該消息的headers（也是一個鍵值對的形式），對比其中的鍵值對是否完全匹配Queue與Exchange綁定時指定的鍵值對；如果完全匹配則消息會路由到該Queue，否則不會路由到該Queue。
該類型的Exchange沒有用到過（不過也應該很有用武之地），所以不做介紹。

RPC####

MQ本身是基于異步的消息處理，前面的示例中所有的生產(chǎn)者（P）將消息發(fā)送到RabbitMQ后不會知道消費者（C）處理成功或者失?。ㄉ踔吝B有沒有消費者來處理這條消息都不知道）。
但實際的應用場景中，我們很可能需要一些同步處理，需要同步等待服務端將我的消息處理完成后再進行下一步處理。這相當于RPC（Remote Procedure Call，遠程過程調(diào)用）。在RabbitMQ中也支持RPC。


RabbitMQ基礎概念詳細介紹
RabbitMQ中實現(xiàn)RPC的機制是：

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

參考連接：
http://www.rabbitmq.com/getstarted.html,
http://www.rabbitmq.com/#getstarted,
http://www.diggerplus.org/archives/3110.

最后編輯于 ：
?著作權歸作者所有,轉載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時請結合常識與多方信息審慎甄別。
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務。

相關閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容