RabbitMQ消息隊列（一）: Detailed Introduction 詳細介紹

1. 歷史

RabbitMQ是一個由erlang開發的AMQP（Advanced Message Queue ）的開源實現。AMQP 的出現其實也是應了廣大人民羣衆的需求，雖然在同步消息通信的世界裏有不少公開標準（如 COBAR的 IIOP ，或者是 SOAP 等），可是在異步消息處理中卻不是這樣，只有大企業有一些商業實現（如微軟的 MSMQ ，IBM 的 Websphere MQ 等），所以，在 2006 年的 6 月，Cisco 、Redhat、iMatix 等聯合制定了 AMQP 的公開標準。

RabbitMQ是由RabbitMQ
Technologies Ltd開發而且提供商業支持的。該公司在2010年4月被SpringSource（VMWare的一個部門）收購。在2013年5月被併入Pivotal。其實VMWare，Pivotal和EMC本質上是一家的。不一樣的是VMWare是獨立上市子公司，而Pivotal是整合了EMC的某些資源，如今並無上市。

RabbitMQ的官網是http://www.rabbitmq.com

2. 應用場景

言歸正傳。RabbitMQ，或者說AMQP解決了什麼問題，或者說它的應用場景是什麼？

對於一個大型的軟件系統來講，它會有不少的組件或者說模塊或者說子系統或者（subsystem or Component or submodule）。那麼這些模塊的如何通訊？這和傳統的IPC有很大的區別。傳統的IPC不少都是在單一系統上的，模塊耦合性很大，不適合擴展（Scalability）；若是使用socket那麼不一樣的模塊的確能夠部署到不一樣的機器上，可是仍是有不少問題須要解決。好比：

1）信息的發送者和接收者如何維持這個鏈接，若是一方的鏈接中斷，這期間的數據如何方式丟失？

2）如何下降發送者和接收者的耦合度？

3）如何讓Priority高的接收者先接到數據？

4）如何作到load balance？有效均衡接收者的負載？

5）如何有效的將數據發送到相關的接收者？也就是說將接收者subscribe 不一樣的數據，如何作有效的filter。

6）如何作到可擴展，甚至將這個通訊模塊發到cluster上？

7）如何保證接收者接收到了完整，正確的數據？

AMDQ協議解決了以上的問題，而RabbitMQ實現了AMQP。

3. 系統架構

成爲系統架構可能不太合適，可能叫應用場景的系統架構更合適。

這個系統架構圖版權屬於sunjun041640。

RabbitMQ Server： 也叫broker server，它不是運送食物的卡車，而是一種傳輸服務。原話是RabbitMQisn’t a food truck, it’s a delivery service. 他的角色就是維護一條從Producer到Consumer的路線，保證數據可以按照指定的方式進行傳輸。可是這個保證也不是100%的保證，可是對於普通的應用來講這已經足夠了。固然對於商業系統來講，能夠再作一層數據一致性的guard，就能夠完全保證系統的一致性了。

Client A & B： 也叫Producer，數據的發送方。createmessages and publish (send) them to a broker server (RabbitMQ).一個Message有兩個部分：payload（有效載荷）和label（標籤）。payload顧名思義就是傳輸的數據。label是exchange的名字或者說是一個tag，它描述了payload，並且RabbitMQ也是經過這個label來決定把這個Message發給哪一個Consumer。AMQP僅僅描述了label，而RabbitMQ決定了如何使用這個label的規則。

Client 1，2，3：也叫Consumer，數據的接收方。Consumersattach to a broker server (RabbitMQ) and subscribe to a queue。把queue比做是一個有名字的郵箱。當有Message到達某個郵箱後，RabbitMQ把它發送給它的某個訂閱者即Consumer。固然可能會把同一個Message發送給不少的Consumer。在這個Message中，只有payload，label已經被刪掉了。對於Consumer來講，它是不知道誰發送的這個信息的。就是協議自己不支持。可是固然了若是Producer發送的payload包含了Producer的信息就另當別論了。

對於一個數據從Producer到Consumer的正確傳遞，還有三個概念須要明確：exchanges, queues and bindings。

Exchanges are where producers publish their messages.

Queuesare where the messages end up and are received by consumers

Bindings are how the messages get routed from the exchange to particular queues.

還有幾個概念是上述圖中沒有標明的，那就是Connection（鏈接），Channel（通道，頻道）。

Connection： 就是一個TCP的鏈接。Producer和Consumer都是經過TCP鏈接到RabbitMQ Server的。之後咱們能夠看到，程序的起始處就是創建這個TCP鏈接。

Channels： 虛擬鏈接。它創建在上述的TCP鏈接中。數據流動都是在Channel中進行的。也就是說，通常狀況是程序起始創建TCP鏈接，第二步就是創建這個Channel。

那麼，爲何使用Channel，而不是直接使用TCP鏈接？

對於OS來講，創建和關閉TCP鏈接是有代價的，頻繁的創建關閉TCP鏈接對於系統的性能有很大的影響，並且TCP的鏈接數也有限制，這也限制了系統處理高併發的能力。可是，在TCP鏈接中創建Channel是沒有上述代價的。對於Producer或者Consumer來講，能夠併發的使用多個Channel進行Publish或者Receive。有實驗代表，1s的數據能夠Publish10K的數據包。固然對於不一樣的硬件環境，不一樣的數據包大小這個數據確定不同，可是我只想說明，對於普通的Consumer或者Producer來講，這已經足夠了。若是不夠用，你考慮的應該是如何細化split你的設計。

4. 進一步的細節闡明

4.1 使用ack確認Message的正確傳遞

默認狀況下，若是Message 已經被某個Consumer正確的接收到了，那麼該Message就會被從queue中移除。固然也可讓同一個Message發送到不少的Consumer。

若是一個queue沒被任何的Consumer Subscribe（訂閱），那麼，若是這個queue有數據到達，那麼這個數據會被cache，不會被丟棄。當有Consumer時，這個數據會被當即發送到這個Consumer，這個數據被Consumer正確收到時，這個數據就被從queue中刪除。

那麼什麼是正確收到呢？經過ack。每一個Message都要被acknowledged（確認，ack）。咱們能夠顯示的在程序中去ack，也能夠自動的ack。若是有數據沒有被ack，那麼：

RabbitMQ Server會把這個信息發送到下一個Consumer。

若是這個app有bug，忘記了ack，那麼RabbitMQ Server不會再發送數據給它，由於Server認爲這個Consumer處理能力有限。

並且ack的機制能夠起到限流的做用（Benefitto throttling）：在Consumer處理完成數據後發送ack，甚至在額外的延時後發送ack，將有效的balance Consumer的load。

固然對於實際的例子，好比咱們可能會對某些數據進行merge，好比merge 4s內的數據，而後sleep 4s後再獲取數據。特別是在監聽系統的state，咱們不但願全部的state實時的傳遞上去，而是但願有必定的延時。這樣能夠減小某些IO，並且終端用戶也不會感受到。

4.2 Reject a message

有兩種方式，第一種的Reject可讓RabbitMQ Server將該Message 發送到下一個Consumer。第二種是從queue中當即刪除該Message。

4.3 Creating a queue

Consumer和Procuder均可以經過 queue.declare 建立queue。對於某個Channel來講，Consumer不能declare一個queue，卻訂閱其餘的queue。固然也能夠建立私有的queue。這樣只有app自己纔可使用這個queue。queue也能夠自動刪除，被標爲auto-delete的queue在最後一個Consumer unsubscribe後就會被自動刪除。那麼若是是建立一個已經存在的queue呢？那麼不會有任何的影響。須要注意的是沒有任何的影響，也就是說第二次建立若是參數和第一次不同，那麼該操做雖然成功，可是queue的屬性並不會被修改。

那麼誰應該負責建立這個queue呢？是Consumer，仍是Producer？

若是queue不存在，固然Consumer不會獲得任何的Message。可是若是queue不存在，那麼Producer Publish的Message會被丟棄。因此，仍是爲了數據不丟失，Consumer和Producer都try to create the queue！反正無論怎麼樣，這個接口都不會出問題。

queue對load balance的處理是完美的。對於多個Consumer來講，RabbitMQ 使用循環的方式（round-robin）的方式均衡的發送給不一樣的Consumer。

4.4 Exchanges

從架構圖能夠看出，Procuder Publish的Message進入了Exchange。接着經過「routing keys」， RabbitMQ會找到應該把這個Message放到哪一個queue裏。queue也是經過這個routing keys來作的綁定。

有三種類型的Exchanges：direct, fanout,topic。 每一個實現了不一樣的路由算法（routing algorithm）。

· Direct exchange: 若是 routing key 匹配, 那麼Message就會被傳遞到相應的queue中。其實在queue建立時，它會自動的以queue的名字做爲routing key來綁定那個exchange。

· Fanout exchange: 會向響應的queue廣播。

· Topic exchange: 對key進行模式匹配，好比ab*能夠傳遞到全部ab*的queue。

4.5 Virtual hosts

每一個virtual host本質上都是一個RabbitMQ Server，擁有它本身的queue，exchagne，和bings rule等等。這保證了你能夠在多個不一樣的application中使用RabbitMQ。

接下來我會使用Python來講明RabbitMQ的使用方法。

原文地址：www.liuhaihua.cn/archives/48…