rabbitmq簡介

簡介

RabbitMQ的官方站：http://www.rabbitmq.com/

rabbitMQ是一個在AMQP協議標準基礎上完整的，可服用的企業消息系統。他遵循Mozilla Public License開源協議。採用 Erlang 實現的工業級的消息隊列(MQ)服務器。
       AMQP(高級消息隊列協議) 是一個異步消息傳遞所使用的應用層協議規範，做爲線路層協議，而不是API（例如JMS），AMQP 客戶端可以無視消息的來源任意發送和接受信息。AMQP的原始用途只是爲金融界提供一個能夠彼此協做的消息協議，而如今的目標則是爲通用消息隊列架構提供通用構建工具。所以，面向消息的中間件 （MOM）系統，例如發佈/訂閱隊列，沒有做爲基本元素實現。反而經過發送簡化的AMQ實體，用戶被賦予了構建例如這些實體的能力。這些實體也是規範的一 部分，造成了在線路層協議頂端的一個層級：AMQP模型。這個模型統一了消息模式，諸如以前提到的發佈/訂閱，隊列，事務以及流數據，而且添加了額外的特性，例如更易於擴展，基於內容的路由。

AMQP當中有四個概念很是重要

1. virtual host，虛擬主機
2. exchange，交換機
3. queue，隊列
4. binding，綁定

一個虛擬主機持有一組交換機、隊列和綁定。

爲何須要多個虛擬主機呢？由於RabbitMQ當中，用戶只能在虛擬主機的粒度進行權限控制。所以，若是須要禁止A組訪問B組的交換機/隊列/綁定，必須爲A和B分別建立一個虛擬主機。每個RabbitMQ服務器都有一個默認的虛擬主機/。

隊列（Queues）是你的消息（messages）的終點，能夠理解成裝消息的容器。消息就一直在裏面，直到有客戶端（也就是消費者，Consumer）鏈接到這個隊列而且將其取走爲止。不過，也能夠將一個隊列配置成這樣的：一旦消息進入這個隊列，此消息就被刪除。

隊列是由消費者（Consumer）經過程序創建的，不是經過配置文件或者命令行工具。這沒什麼問題，若是一個消費者試圖建立一個已經存在的隊列，RabbitMQ會直接忽略這個請求。所以咱們能夠將消息隊列的配置寫在應用程序的代碼裏面。

而要把一個消息放進隊列前，須要有一個交換機（Exchange）。

交換機（Exchange）能夠理解成具備路由表的路由程序。每一個消息都有一個稱爲路由鍵（routing key）的屬性，就是一個簡單的字符串。交換機當中有一系列的綁定（binding），即路由規則（routes）。（例如，指明具備路由鍵 「X」 的消息要到名爲timbuku的隊列當中去。）

消費者程序（Consumer）要負責建立你的交換機。交換機能夠存在多個，每一個交換機在本身獨立的進程當中執行，所以增長多個交換機就是增長多個進程，能夠充分利用服務器上的CPU核以便達到更高的效率。例如，在一個8核的服務器上，能夠建立5個交換機來用5個核，另外3個核留下來作消息處理。相似的，在RabbitMQ的集羣當中，你能夠用相似的思路來擴展交換機一邊獲取更高的吞吐量。

交換機如何判斷要把消息送到哪一個隊列？你須要路由規則，即綁定（binding）。一個綁定就是一個相似這樣的規則：將交換機「desert（沙漠）」當中具備路由鍵「阿里巴巴」的消息送到隊列「hideout（山洞）」裏面去。換句話說，一個綁定就是一個基於路由鍵將交換機和隊列鏈接起來的路由規則。例如，具備路由鍵「audit」的消息須要被送到兩個隊列，「log-forever」和「alert-the-big-dude」。要作到這個，就須要建立兩個綁定，每一個都鏈接一個交換機和一個隊列，二者都是由「audit」路由鍵觸發。在這種狀況下，交換機會複製一份消息而且把它們分別發送到兩個隊列當中。交換機不過就是一個由綁定構成的路由表。

交換機有多種類型。他們都是作路由的，可是它們接受不一樣類型的綁定。爲何不建立一種交換機來處理全部類型的路由規則呢？由於每種規則用來作匹配分子的CPU開銷是不一樣的。例如，一個「topic」類型的交換機試圖將消息的路由鍵與相似「dogs.*」的模式進行匹配。匹配這種末端的通配符比直接將路由鍵與「dogs」比較（「direct」類型的交換機）要消耗更多的CPU。若是你不須要「topic」類型的交換機帶來的靈活性，你能夠經過使用「direct」類型的交換機獲取更高的處理效率。那麼有哪些類型，他們又是怎麼處理的呢？

　　Exchange

1. Exchange Direct

   Exchange Fanout

   Exchange Topic

---

持久化

你花了大量的時間來建立隊列、交換機和綁定，而後，服務器程序掛了。你的隊列、交換機和綁定怎麼樣了？還有，放在隊列裏面可是還沒有處理的消息們呢？

若是你是用默認參數構造的這一切的話，那麼，他們都灰飛煙滅了。RabbitMQ重啓以後會乾淨的像個新生兒。你必須重作全部的一切，亡羊補牢，如何避免未來再度發生此類杯具？

隊列和交換機有一個建立時候指定的標誌durable。durable的惟一含義就是具備這個標誌的隊列和交換機會在重啓以後從新創建，它不表示說在隊列當中的消息會在重啓後恢復。那麼如何才能作到不僅是隊列和交換機，還有消息都是持久的呢？

可是首先須要考慮的問題是：是否真的須要消息的持久化？若是須要重啓後消息能夠回覆，那麼它須要被寫入磁盤。但即便是最簡單的磁盤操做也是要消耗時間的。因此須要衡量判斷。

當你將消息發佈到交換機的時候，能夠指定一個標誌「Delivery Mode」（投遞模式）。根據你使用的AMQP的庫不一樣，指定這個標誌的方法可能不太同樣。簡單的說，就是將Delivery Mode設置成2，也就是持久的（persistent）便可。通常的AMQP庫都是將Delivery Mode設置成1，也就是非持久的。因此要持久化消息的步驟以下：

1. 將交換機設成 durable。
2. 將隊列設成 durable。
3. 將消息的 Delivery Mode 設置成2 。

綁定（Bindings）怎麼辦？綁定沒法在建立的時候設置成durable。沒問題，若是你綁定了一個durable的隊列和一個durable的交換機，RabbitMQ會自動保留這個綁定。相似的，若是刪除了某個隊列或交換機（不管是否是durable），依賴它的綁定都會自動刪除。

注意：

• RabbitMQ 不容許你綁定一個非堅固（non-durable）的交換機和一個durable的隊列。反之亦然。要想成功必須隊列和交換機都是durable的。
• 一旦建立了隊列和交換機，就不能修改其標誌了。例如，若是建立了一個non-durable的隊列，而後想把它改變成durable的，惟一的辦法就是刪除這個隊列而後重現建立。所以，最好仔細檢查建立的標誌。