RabbitMQ入門指南

簡介

RabbitMQ是實現了高級消息隊列協議（AMQP）的開源消息代理（英語：Message broker）軟件（亦稱面向消息的中間件（英語：Message-oriented middleware））。RabbitMQ服務器是用Erlang語言編寫的，而羣集和故障轉移是構建在OTP(Open Telecom Platform)上的。全部主要的編程語言均有與代理接口通信的客戶端函式庫。

主要特性

可靠性（Reliability）

RabbitMQ 使用一些機制來保證可靠性，如持久化、傳輸確認、發佈確認。

靈活的路由（Flexible Routing）

在消息進入隊列以前，經過 Exchange 來路由消息的。對於典型的路由功能，RabbitMQ 已經提供了一些內置的 Exchange 來實現。針對更復雜的路由功能，能夠將多個 Exchange 綁定在一塊兒，也經過插件機制實現本身的 Exchange 。

消息集羣（Clustering）

多個 RabbitMQ 服務器能夠組成一個集羣，造成一個邏輯 Broker 。

高可用（Highly Available Queues）

隊列能夠在集羣中的機器上進行鏡像，使得在部分節點出問題的狀況下隊列仍然可用。

多種協議（Multi-protocol）

RabbitMQ 支持多種消息隊列協議，好比 STOMP、MQTT 等等。

多語言客戶端（Many Clients）

RabbitMQ 幾乎支持全部經常使用語言，好比 Java、.NET、Ruby 等等。

管理界面（Management UI）

RabbitMQ 提供了一個易用的用戶界面，使得用戶能夠監控和管理消息 Broker 的許多方面。

跟蹤機制（Tracing）

若是消息異常，RabbitMQ 提供了消息跟蹤機制，使用者能夠找出發生了什麼。

插件機制（Plugin System）

RabbitMQ 提供了許多插件，來從多方面進行擴展，也能夠編寫本身的插件。

基本概念（如下使用AMQP-0-9-1版本）

先放一張主要結構圖

Broker

Broker（能夠理解爲RabbitMQ）從發佈者(發佈消息的應用程序，也稱爲生產者)接收消息，並將其路由到消費者(處理消息的應用程序)。

Exchange

Exchange是 AMQP 0-9-1實體，用於發送消息。 Exchange接收消息並將其路由到零個或多個隊列。 所使用的路由算法取決於稱爲綁定的交換類型和規則。 Amqp 0-9-1型經紀商提供四種交易所類型：

類型	默認名稱
Direct exchange	空字符串或amq.direct
Fanout exchange	amq.fanout
Topic exchange	amq.topic
Headers exchange	amq.match(以及 RabbitMQ 中的 amq.headers)

Default Exchange

默認交換是直接交換，沒有代理預先聲明的名稱(空字符串)。 它有一個特殊的屬性，這使得它對簡單的應用程序很是有用: 建立的每一個隊列都自動用與隊列名相同的路由鍵綁定到它。

Direct Exchange

直接交換器根據郵件路由鍵將郵件傳遞到隊列。 直接交換對於消息的單播路由是理想的(儘管它們也能夠用於廣播路由)。 如下是它的工做原理:

• 隊列使用路由鍵 K 綁定到交換機
• 當具備路由鍵 R 的新消息到達直接交換機時，若是是 kr，則交換將其路由到隊列

Fanout Exchange

扇出（叫廣播可能好理解一些）交換將消息路由到綁定到它的全部隊列，而路由鍵被忽略。 若是 n 個隊列綁定到扇出交換器，當新消息發佈到該交換器時，該消息的副本將傳遞到全部 n 個隊列。 扇出交換是消息廣播路由的理想選擇。也就是說發送消息的key變成了Exchange，消費者能夠直接經過Fanout Exchange拉去消息，實現廣播/主題訂閱。

由於扇出交換機向每一個綁定到它的隊列發送一個消息的副本，它的用法很是類似:

• 大型多玩家在線(MMO)遊戲可使用它來進行排行榜更新或其餘全球活動
• 體育新聞網站可使用 fanout 交易平臺向移動客戶發佈接近實時的分數更新
• 分佈式系統能夠廣播各類狀態和配置更新
• 羣聊可使用扇出交換機在參與者之間分發消息(儘管 AMQP 沒有內置的存在概念，所以 XMPP 多是更好的選擇)

Topic Exchange

主題交換根據消息路由鍵與用於將隊列綁定到交換機的模式之間的匹配將消息路由到一個或多個隊列。 話題交換類型一般用於實現各類各樣的發佈/訂閱模式變化。 主題交換一般用於消息的多播路由。

主題交換有一組很是普遍的用例。 每當一個問題涉及到多個消費者 / 應用程序，這些消費者 / 應用程序有選擇地選擇要接收哪一種類型的消息時，就應該考慮使用主題交換。

與Fanout Exchange不一樣的是，Topic Exchange支持更多形式的綁定，能夠動態的將Queue綁定在Exchange，更加靈活。

使用場景：

• 後臺任務處理由多個工做者完成，每一個工做者都可以處理特定的任務集
• 分佈式架構 / 操做系統特定的軟件構建或打包，其中每一個構建器只能處理一個架構或操做系統

Header Exchange

Header 交換是爲了在多個屬性上進行路由而設計的，這些屬性比路由鍵更容易表示爲消息Header。Header Exchange會忽略RoutingKey。 相反，用於路由的屬性取自 header 屬性。 若是消息頭的值等於綁定時指定的值，則認爲消息是匹配的。

Queue

隊列，在使用隊列以前，必須聲明它。 若是隊列不存在，則聲明該隊列將致使建立該隊列。 若是隊列已經存在而且其屬性與聲明中的屬性相同，則聲明將沒有任何效果。 當現有隊列屬性與聲明中的屬性不一致時，將引起代碼爲406(pretirement failed)的通道級異常。

Bingding

綁定是Exchange將消息分發到隊列的規則。 要實現交換機 E 將消息分發到隊列 Q，Q 必須綁定到 E。綁定可能具備某些交換機類型使用的可選路由鍵屬性。 RoutingKey的用途是選擇發佈到交換器的某些消息，以便將其分發到綁定隊列。 換句話說，RoutingKey的做用相似於過濾器。

Consumer

消費者。每一個消費者(訂閱)都有一個標識符，稱爲ConsumerTag。 它能夠用來退訂消息。 ConsumerTag只是一個字符串。

Message Acknowledgements

簡稱ACK，消息確認機制。

因爲網絡不可靠，應用程序失敗，所以一般須要某種形式的處理確認。 在消費成功後，能夠顯式的通知Broker消息處理完成。

Connection

一半鏈接的存活週期是比較長的，一個Connection對應一個TCP鏈接。爲了提升性能，不會每次接受/發送消息都建立新鏈接，因此設計了Channel的概念。

Channel

有些應用程序須要多個到Broker的鏈接。 可是，同時打開多個 TCP 鏈接是不合適的，由於這樣作會消耗系統資源。 Amqp 0-9-1鏈接與通道複用，Channel能夠認爲是"共享單個 TCP 鏈接的輕量級鏈接"。

Vhost

爲了使單個Broker可以使用載多個獨立的"環境"(用戶組、交換器、隊列等) ，AMQP 包含了虛擬主機(vhosts)的概念。 它們相似於許多流行 Web 服務器使用的虛擬主機，並提供 AMQP 實體所在的徹底隔離的環境。 Amqp 客戶端指定在 AMQP 鏈接協商期間要使用的 vhosts。

能夠經過Vhost來實現一些權限的功能，好比在多系統下共用一個MQ集羣是，能夠分配不一樣的Vhost/User來控制數據的權限，保障安全。