RabbitMq基礎教程之基本概念

RabbitMq基礎教程之基本概念

RabbitMQ是一個消息隊列，和Kafka以及阿里的ActiveMQ從屬性來說，乾的都是一回事。消息隊列的主要目的實現消息的生產者和消費者之間的解耦，支持多應用之間的異步協調工做

因爲工做緣由，接觸和使用rabbitmq做爲生產環境下的消息隊列，所以準備寫一些博文，記錄下這個過程當中的收貨；而開篇除了環境搭建以外，就是對於其內部的基本概念進行熟悉和了解了。

基礎環境搭建能夠參考： 《RabbitMq基礎教程之安裝與測試》

本文則主要集中在如下幾點：

• 幾個基本概念（Message, Publisher, Exchange, Binding, Queue, Channel, Consuer, Virtual host)
• 消息分發的幾種策略
• ACK是什麼鬼

<!-- more -->

I. 基本概念

1. 消息隊列

首先來一張消息隊列的經典圖，能夠劃分爲三個角色: Producer, Queue, Consumer

• Queue：爲承載消息的容器，爲何是隊列而不是棧呢？主要是由於絕大部分的場景，咱們都是但願消息是先進先出，有順序的
• Producer：生產者，就是產生消息，並不斷往隊列塞的角色
• Consumer：消費者，也就是不斷從隊列中獲取消息的角色

看到這個模型，若是對JDK的容器有必定的瞭解，很容易能夠想到藉助 ArrayBlockingQueue 或者 ListBlockingQueue 就能夠實現簡易的消息隊列（也就是咱們常說的生產者-消費者模型）

2. 實例理解消息隊列

其實在生活中，這種模型用得很是多，就好比咱們都會接觸的網購快遞，能夠說是一個典型的消息隊列的case了：

商家不斷的把商品扔給快遞公司（注意不是直接將商品給買家），而快遞公司則將商品根據地質分發對應的買家

對上面這個過程進行拆解，能夠映射扮演的角色

• 商品：Message，傳遞的消息，由商家投遞給快遞公司時，須要進行打包（通常Producer生產消息也會將實體數據進行封裝）
• 商家：Produer 生產者
• 快遞公司： Queue，消息的載體
• 買家：Consumer 消費者

那麼快遞公司時怎麼知道要把商品給對應的買家呢？根據包裹上的地址+電話

• 一樣消息隊列也須要一個映射規則，實現Message和Consumer之間的路由

3. RabbitMQ基本概念

經過上面的實例對比，發現基本的消息隊列定義的元素太少，這裏則正好能夠看一下RabbitMQ是怎麼具體來實現消息隊列的

• Message：消息，包含消息頭（即附屬的配置信息）和消息體（即消息的實體內容）
• Publisher：生產者，向交換機發布消息的主體
• Exchange：交換機，用來接收生產者發送的消息並將這些消息路由給服務器中的隊列
• Binding：綁定，用於給Exchange和Queue創建關係，就是咱們熟知的配對的紅娘
• Queue：消息隊列，用來保存消息直到發送給消費者。它是消息的容器，也是消息的終點。一個消息可投入一個或多個隊列。消息一直在隊列裏面，等待消費者鏈接到這個隊列將其取走。
• Connection：鏈接
• Channel：通道，MQ與外部打交道都是經過Channel來的，發佈消息、訂閱隊列仍是接收消息，這些動做都是經過Channel完成；簡單來講就是消息經過Channel塞進隊列或者流出隊列
• Consumer：消費者，從消息隊列中獲取消息的主體
• Virtual Host: 虛擬主機，表示一批交換器、消息隊列和相關對象。虛擬主機是共享相同的身份認證和加密環境的獨立服務器域。每一個 vhost 本質上就是一個 mini 版的 RabbitMQ 服務器，擁有本身的隊列、交換器、綁定和權限機制。vhost 是 AMQP 概念的基礎，必須在鏈接時指定，RabbitMQ 默認的 vhost 是 /
• Broker：消息隊列服務器實體

上面是一些專業的概念，那麼能夠怎麼映射到前面的快遞上呢？

II. Exchange類型

生產者，將消息投遞給Exchange，而後由Exchange將消息路由到對應的Queue上，供消費者消費，那麼這個路由有哪些方式呢？

1. Direct策略

消息中的路由鍵（routing key）若是和 Binding 中的 binding key 一致， 交換器就將消息發到對應的隊列中

簡單來說，就是路由鍵與隊列名徹底匹配

• 若是一個隊列綁定到交換機要求路由鍵爲「dog」
• 只轉發 routing key 標記爲「dog」的消息，
• 不會轉發「dog.puppy」，也不會轉發「dog.guard」等等
• 它是徹底匹配、單播的模式

舉例說明

Exchange和兩個隊列綁定在一塊兒：

• Q1的bindingkey是orange
• Q2的binding key是black和green.
• 當Producer publish key是orange時, exchange會把它放到Q1上, 若是是black或green就會到Q2上, 其他的Message被丟棄

2. Fanout策略

從上圖也能夠看出，這種策略，將忽略所謂的routing key,將消息分發到全部綁定的Queue上，更加相似咱們理解的廣播模式

3. Topic策略

topic 交換器經過模式匹配分配消息的路由鍵屬性，將路由鍵和某個模式進行匹配，此時隊列須要綁定到一個模式上

能夠理解爲直接策略的進階版，直接策略是徹底精確匹配，而topic則支持正則匹配，知足某類指定規則的（如以xxx開頭的路由鍵），能夠鍵消息分發過去

• # 匹配0個或多個單詞
• * 匹配很少很多一個單詞

一個更直觀的實例以下

Producer發送消息時須要設置routing_key,

• Q1 的binding key 是」.orange.「
• Q2 是 「..rabbit」 和 「lazy.#」：
• 產生一個 test.orange.mm 消息，則會路由到Q1；而若是是 test.orange則沒法路由到Q1,由於Q1的規則是三個單詞，中間一個爲orange，不知足這個規則的都無效
• 產生一個 test.qq.rabbit 或者 lazy.qq 均可以分發到Q2；即路由key爲三個單詞，最後一個爲rabbit或者不限制單詞個數，主要第一個是lazy的消息，均可以分發過來
• 若是產生的是一個 test.orange.rabbit消息，則Q1和Q2均可以知足

4. Headers策略

這個實際上用得很少，它是根據Message的一些頭部信息來分發過濾Message，忽略routing key的屬性，若是Header信息和message消息的頭信息相匹配

5. 小結

主要使用的消息分發策略有三個，直接，路由和扇形，簡單的小結下應用場景和區別

a. Direct Exchange

直接徹底匹配模式，適用於精準的消息分發

b. Topic Exchange

Routing Key的匹配模式，支持Routing Key的模糊匹配方式，更適用於多類消息的聚合

c. Fanout Exchange

忽略Routing Key, 將消息分配給全部的Queue，廣播模式，適用於消息的複用場景

III. ACK

消息隊列的一個重要指標，當有消費者獲取了消息以後，對這個消息我應該怎麼辦？是直接刪除仍是等某個合適的機會再刪除？又或者是乾脆不刪除，就留着了？

在實際的應用場景中，消息正常消費以後，咱們但願的是這個消息就不要了，可是消費的過程當中若是出現了bug，則但願不要刪除消息，等我修復這個bug後，能夠把這個消息從新的投遞給我

1. ack機制

Consumer接收到了消息以後，必須返回一個ack的標誌，表示消息是否成功消費，若是返回true，則表示消費成功了，而後這個消息就會從RabbitMQ的隊列中刪掉；若是返回false，且設置爲從新入隊，則這個消息能夠被從新投遞進來

一般實際編碼中，默認是自動ACK的，若是消息的重要性程度較高，咱們應該設置爲主動ACK，在接收到消息以後，自主的返回對應的ACK信息

這一塊更多地內容能夠查看實際使用篇

IV. 其餘

1. 參考

• Consumer Acknowledgements and Publisher Confirms
• RabbitMQ Tutorials
• RabbitMQ】三種Exchange模式——訂閱、路由、通配符模式

2. 一灰灰Blog： https://liuyueyi.github.io/hexblog

一灰灰的我的博客，記錄全部學習和工做中的博文，歡迎你們前去逛逛

3. 聲明

盡信書則不如，已上內容，純屬一家之言，因我的能力有限，不免有疏漏和錯誤之處，如發現bug或者有更好的建議，歡迎批評指正，不吝感激

• 微博地址: 小灰灰Blog
• QQ： 一灰灰/3302797840

4. 掃描關注