前言 RabbitMQ是消息隊列中間件(Message Queue Middleware)中一種,工作雖然有用到,但是卻沒有形成很好的整體包括,主要是一些基礎概念的認識,這裡通過閱讀《RabbitMQ實戰指南》整理筆記併進行代碼實踐,更好地理解RabbitMQ! 本文只通過講解RabbitMQ的一些 ...
前言
RabbitMQ是消息隊列中間件(Message Queue Middleware)中一種,工作雖然有用到,但是卻沒有形成很好的整體包括,主要是一些基礎概念的認識,這裡通過閱讀《RabbitMQ實戰指南》整理筆記併進行代碼實踐,更好地理解RabbitMQ!
本文只通過講解RabbitMQ的一些基礎概念,主要是RabbitMQ的“生產者-消費者”模型涉及到的交換器、路由鍵、綁定鍵、消息路由規則等,下一篇RabbitMQ是如何運轉的?會有簡單介紹RabbitMQ的運轉、RabbitMQ部署,Java代碼實踐。
需要電子書PDF版《RabbitMQ實戰指南》(高清帶標簽)可以評論或者聯繫我
一、MQ的作用
講解RabbitMQ之前先認識下MQ作為消息中間件的作用(優點),使用的時候如果不去思考為什麼用MQ,怎樣更好地才能達到它的作用的話,那都是毫無意義的使用!
1、解耦:可以很好地屏蔽應用程式及平臺之間的特性,充當中間者,鬆散耦合應用程式及平臺,它們彼此不需要瞭解遠程過程調用RPC與網路協議的細節;
2、非同步通信:能提供C/S之間同步與非同步連接,在任何時刻都可以將消息進行傳送或者存儲轉發;
3、可恢復性:當消息接收方宕機或網路不通的情況下,消息轉儲於MQ中,直到網路恢復或接收方恢復再進行轉發;
4、擴展性:提高消息入隊列和處理效率是容易的,只需要另外增加處理過程即可,不需要改變代碼,也不需要調節參數。
5、順序性:由於大部分MQ支持隊列模式,自然也就能保證一定的數據處理順序;
6、緩衝:MQ通過一個緩衝層來幫助任務最高效率執行,寫入MQ的處理會儘可能快速。
二、RabbitMQ的“交換機”模型
RabbitMQ整體的模型其實是一種“生產者-消費者”模型,發送消息的一方稱之為生產者,接收消息一方稱之為消費者。中間會有交換器、隊列、Broker等概念。下圖是簡單的RabbitMQ的模型圖(截圖來自於《RabbitMQ實戰指南》,以下截圖同)
1、生產者-消費者與RabbitMQ Broker
(1)Producer:
投遞消息的一方,創建了消息之後發佈到RabbitMQ中,消息主要包括消息體(Payload)與Label標簽,消息體可以通常是業務數據,比如JSON等,Label則用來表述這條消息,比如一個交換機名稱和一個路由鍵。
生產者把消息交由RabbitMQ,之後會根據標簽把消息發送給感興趣的消費者。
(2 Consumer:
消費者,接收消息的一方,連接到RabbitMQ伺服器,並訂閱到隊列上,當消費者消費一條消息時只是消費了消息體payload,在消息路由過程中,消息的標簽會丟失,存入隊列中只有消息體。消費者不需要知道生產者是誰。
(3)Broker:
消息中間件的服務節點,一個RabbitMQ Broker可以簡單地看做一個RabbitMQ服務節或者RabbitMQ服務實例(大多數情況下可以看做是一臺RabbitMQ的伺服器)
由上圖可知,消息隊列運轉過程是這樣的:
封裝好的消息發送(AMQP命令為Basic.publish)到Broker中,消費者訂閱並接收(Basic.Get/Basic.Consume)消息,之後再進行業務邏輯處理(可以再開另外的進程,不需要與接收消息同一個進程)
2、隊列
RabbitMQ中消息都只能存儲在隊列中,當多個消費者訂閱一個隊列時,隊列中的消息會被平均分攤(Round-Robin),也就是並不是每個消費者都能收到所有的消息並處理。
註意以下幾點:
1)對於生產者生產的消息到隊列中,並不是平均分攤。而是通過路由鍵、綁定鍵、交換器類型三個決定消息最終被哪個消費者消費,之後會介紹!
2)生產者與消費者之間的連接,並不只是通過隊列那麼簡單連接,而是外加通過TCP連接與通道Channel,之後也會介紹
3、交換器、路由鍵、綁定
(1) 交換器(Exchange, X):由上圖交換機模型圖中看不到交換器這個東西,但實際上是存在的,生產者將消息投遞到隊列,然而真實情況是:生產者將消息發送到Exchange,由Exchange再路由到一個或多個隊列中;
交換器的類型有fanout、direct、topic、headers這四種類型,不同的類型的交換器有其獨特的匹配規則,這裡的匹配規則其實就是決定消息最終路由到哪的隊列的關鍵,具體請往下看
(2) 路由鍵(RoutingKey):生產者將消息發送給交換器的時候,會指定RoutingKey指定路由規則,實際情況是需要將RoutingKey、交換器類型、綁定鍵聯合使用才能最終生效。當交換器類型與BindingKey固定情況下,通過執行RoutingKey來決定消息流向哪裡。
(3)綁定(BindingKey):通過綁定鍵將交換器與隊列關聯起來,這樣RabbitMQ就知道如何正確地將消息路由到隊列,其實綁定鍵也是一種路由鍵的一種,不過是用在綁定交換器與隊列的時候。
總結有以下三點:
(1) 生產者將消息發送給哪個Exchange是需要由RoutingKey決定的,生產者需要將Exchange與哪個隊列綁定時需要由BindingKey決定的(當然還要看交換器類型,BindingKey不一定會生效,如fanout類型交換器);
(2) 生產者將消息發送給交換器時,需要一個RoutingKey,當BindingKey和RoutingKey相匹配時,消息會被路由到對象的隊列中(當然也要看交換器類型)。
(3) BindingKey其實也屬於路由鍵的一種,在使用邦定的時候,需要的路由鍵是BingdingKey,在發送消息的時,需要的路由鍵是RoutingKey
4、交換器類型
為什麼非要介紹交換器類型呢?上文中也提到過交換器類型關係到具體的消息路由途徑,處路由鍵、綁定鍵之外的還需要關註交換器的類型。不同的交換器會有不同的匹配規則。
RabbitMQ常用的交換器類型有fanout、direct、topic、headers這四種類型
(1)fanout:它會把所有的交換器上的消息路由到所有與該交換器邦定的隊列中,不需要BindingKey生效
(2)direct:它會把消息路由到BindingKey與RoutingKey完全匹配的隊列中。比如在發送消息的時候,設置Label中RoutingKey為warning,則消息會路由到Queue1與Queue2上(請看下圖)。
(3)topic:是direct上的擴展,同樣是利用RoutingKey與BindingKey相匹配,但是匹配規則不一樣,支持模糊匹配。有如下的規則
-
-
-
-
- RoutingKey為一個點號“.”分隔的字元串,每個被隔開的獨立字元串即為一個單詞,是匹配的單位;
- BindingKey和RoutingKey一樣,也是"."分割的字元串;
- 但不同的是BindingKey,可以用“#”,“*”進行類似於占位符的模糊匹配,“#”表示一個單詞,"*"表示多個單詞(也可以是零個)
-
-
-
比如:
RoutingKey為com.hidden.client的消息只會到隊列Queue2中:因為只有Queue2的BindingKey=*.*.client匹配com.hidden.client
RoutingKey為com.rabbitmq.client的消息會到隊列Queue1-2中: 因為Queue1的BindingKey=*.rabbitmq.*.匹配com.rabbitmq.client,Queue2的BindingKey=*.*.client匹配com.rabbitmq.client
RoutingKey為java.rabbitmq.demo的消息只會到隊列Queue1中:因為只有Queue1的BindingKey=*.rabbitmq.*.匹配java.rabbitmq.demo
RoutingKey為java.util.concurrent的消息會被丟棄或者返回給生產者(需要設置)
(4)headers:依賴發送消息內容中的hearders屬性進行匹配,在綁定隊列和交換器時指定一組鍵值對,這裡的也就是headers,當發送消息到交換器時,RabbitMQ會獲取到該消息的headers,通過比較會路由到相關隊列中,這種交換器性能會很差,一般不會使用。
以上內容總結起來只是介紹了RabbitMQ的從生產者產生消息到消費者消費消息過程中涉及到的概念。還未介紹具體的RabbitMQ是如何運轉的,比如生產者是怎樣建立連接生成消息的,消費者又是怎樣讀取消息的,這將是下一篇RabbitMQ是如何運轉的?主要介紹的。