全網最全RabbitMQ總結,別再說你不會RabbitMQ

Java識堂發表於2020-01-21
在這裡插入圖片描述
在這裡插入圖片描述

RabbitMQ入門教程

當初我學RabbitMQ的時候,第一時間就上GitHub找相應的教程,但是令我很失望的是沒有找到,Spring,Mybatis之類的教程很多,而RabbitMQ的教程幾乎找不到,看的最多的就是朱小廝大佬的部落格。後來想著索性自己總結一下吧,有不恰當的地方歡迎小夥伴指出。

這篇文章主要是對著我在GitHub上的原始碼解釋的,因此本文並沒有太多的原始碼。寫了挺長時間的,為了防止迷路,歡迎大家star和fork

在這裡插入圖片描述
在這裡插入圖片描述

github地址:https://github.com/erlieStar/rabbitmq-examples 在這裡插入圖片描述

前言

我們先來看一下一條訊息在RabbitMQ中的流轉過程 在這裡插入圖片描述

圖示的主要流程如下

  1. 生產者傳送訊息的時候指定RoutingKey,然後訊息被髮送到Exchange
  2. Exchange根據一些列規則將訊息路由到指定的佇列中
  3. 消費者從佇列中消費訊息

整個流程主要就4個參與者message,exchange,queue,consumer,我們就來認識一下這4個參與者

Message

訊息可以設定一些列屬性,每種屬性的作用可以參考《深入RabbitMQ》一書

屬性名 用處
contentType 訊息體的MIME型別,如application/json
contentEncoding 訊息的編碼型別,如是否壓縮
messageId 訊息的唯一性標識,由應用進行設定
correlationId 一般用作關聯訊息的message-id,常用於訊息的響應
timestamp 訊息的建立時刻,整型,精確到秒
expiration 訊息的過期時刻,字串,但是呈現格式為整型,精確到秒
deliveryMode 訊息的持久化型別 ,1為非持久化,2為持久化,效能影響巨大
appId 應用程式的型別和版本號
userId 標識已登入使用者,極少使用
type 訊息型別名稱,完全由應用決定如何使用該欄位
replyTo 構建回覆訊息的私有響應佇列
headers 鍵/值對錶,使用者自定義任意的鍵和值
priority 指定佇列中訊息的優先順序

Exchange

接收訊息,並根據路由鍵轉發訊息到所繫結的佇列,常用的屬性如下

交換機屬性 型別
name 交換器名稱
type 交換器型別,有如下四種,direct,topic,fanout,headers
durability 是否需要持久化,true為持久化。持久化可以將交換器存檔,在伺服器重啟的時候不會丟失相關資訊
autoDelete 與這個Exchange繫結的Queue或Exchange都與此解綁時,會刪除本交換器
internal 設定是否內建,true為內建。如果是內建交換器,客戶端無法傳送訊息到這個交換器中,只能通過交換器路由到交換器這種方式
argument 其他一些結構化引數

我們最常使用的就是type屬性,下面就詳細解釋type屬性 在這裡插入圖片描述

Fanout Exchange

這裡寫圖片描述
這裡寫圖片描述

傳送到該交換機的訊息都會路由到與該交換機繫結的所有佇列上,可以用來做廣播

不處理路由鍵,只需要簡單的將佇列繫結到交換機上

Fanout交換機轉發訊息是最快的

Direct Exchage

這裡寫圖片描述
這裡寫圖片描述

把訊息路由到BindingKey和RoutingKey完全匹配的佇列中

Topic Exchange

這裡寫圖片描述
這裡寫圖片描述

前面說到,direct型別的交換器路由規則是完全匹配RoutingKey和BindingKey。topic和direct類似,也是將訊息傳送到RoutingKey和BindingKey相匹配的佇列中,只不過可以模糊匹配。

  1. RoutinKey為一個被“.”號分割的字串(如com.rabbitmq.client)
  2. BindingKey和RoutingKey也是“.”號分割的字串
  3. BindKey中可以存在兩種特殊字串“*”和“#”,用於做模糊匹配,其中“*”用於匹配不多不少一個詞,“#”用於匹配多個單詞(包含0個,1個)
BindIngKey 能夠匹配到的RoutingKey
java.# java.lang,java.util, java.util.concurrent
java.* java.lang,java.util
*.*.uti com.javashitang.util,org.spring.util

假如現在有2個RoutingKey為java.lang和java.util.concurrent的訊息,java.lang會被路由到Consumer1和Consumer2,java.util.concurrent會被路由到Consumer2。

在這裡插入圖片描述
在這裡插入圖片描述

Headers Exchange

headers型別的交換器不依賴於路由鍵的匹配規則來路由訊息,而是根據傳送訊息內容中的headers屬性進行匹配。headers型別的交換器效能差,不實用,基本上不會使用。

Queue

佇列的常見屬性如下

引數名 用處
queue 佇列的名稱
durable 是否持久化,true為持久化。持久化的佇列會存檔,在伺服器重啟的時候可以保證不丟失相關資訊
exclusive 設定是否排他,true為排他。如果一個佇列被宣告為排他佇列,該佇列僅對首次宣告他它的連線可見,並在連線斷開時自動刪除(即一個佇列只能有一個消費者)
autoDelete 設定是否自動刪除,true為自動刪除,自動刪除的前提是,至少一個消費者連線到這個佇列,之後所有與這個連線的消費者都斷開時,才會自動刪除
arguments 設定佇列的其他引數,如x-message-ttl,x-max-length

arguments中可以設定的佇列的常見引數如下

引數名 目的
x-dead-letter-exchange 死信交換器
x-dead-letter-routing-key 死信訊息的可選路由鍵
x-expires 佇列在指定毫秒數後被刪除
x-ha-policy 建立HA佇列
x-ha-nodes HA佇列的分佈節點
x-max-length 佇列的最大訊息數
x-message-ttl 毫秒為單位的訊息過期時間,佇列級別
x-max-priority 最大優先值為255的佇列優先排序功能

rabbitmq-api(rabbitmq api的使用)

在這裡插入圖片描述
在這裡插入圖片描述

chapter_1: 快速開始,手寫一個RabbitMQ的生產者和消費者

chapter_2: 演示了各種exchange的使用

來回顧一下上面說的各種exchange機器路由規則

交換器型別 路由規則
fanout 傳送到該交換機的訊息都會路由到與該交換機繫結的所有佇列上,可以用來做廣播
direct 把訊息路由到BindingKey和RoutingKey完全匹配的佇列中
topic topic和direct類似,也是將訊息傳送到RoutingKey和BindingKey相匹配的佇列中,只不過可以模糊匹配
headers 效能差,基本不會使用
在這裡插入圖片描述
在這裡插入圖片描述

chapter_3: 拉取訊息

訊息的獲得方式有2種

  1. 拉取訊息(get message)

  2. 推送訊息(consume message)

那我們應該拉取訊息還是推送訊息?get是一個輪詢模型,而consumer是一個推送模型。get模型會導致每條訊息都會產生與RabbitMQ同步通訊的開銷,這一個請求由傳送請求幀的客戶端應用程式和傳送應答的RabbitMQ組成。所以推送訊息,避免拉取

chapter_4: 手動ack

訊息的確認方式有2種

  1. 自動確認(autoAck=true)
  2. 手動確認(autoAck=false)

消費者在消費訊息的時候,可以指定autoAck引數

String basicConsume(String queue, boolean autoAck, Consumer callback)

autoAck=false: RabbitMQ會等待消費者顯示回覆確認訊息後才從記憶體(或者磁碟)中移出訊息

autoAck=true: RabbitMQ會自動把傳送出去的訊息置為確認,然後從記憶體(或者磁碟)中刪除,而不管消費者是否真正的消費了這些訊息

手動確認的方法如下,有2個引數

basicAck(long deliveryTag, boolean multiple)

deliveryTag: 用來標識通道中投遞的訊息。RabbitMQ 推送訊息給Consumer時,會附帶一個deliveryTag,以便Consumer可以在訊息確認時告訴RabbitMQ到底是哪條訊息被確認了。 RabbitMQ保證在每個通道中,每條訊息的deliveryTag從1開始遞增

multiple=true: 訊息id<=deliveryTag的訊息,都會被確認

myltiple=false: 訊息id=deliveryTag的訊息,都會被確認

訊息一直不確認會發生啥?

如果佇列中的訊息傳送到消費者後,消費者不對訊息進行確認,那麼訊息會一直留在佇列中,直到確認才會刪除。 如果傳送到A消費者的訊息一直不確認,只有等到A消費者與rabbitmq的連線中斷,rabbitmq才會考慮將A消費者未確認的訊息重新投遞給另一個消費者

chapter_5: 拒絕訊息的兩種方式

確認訊息只有一種方法

  1. basicAck(long deliveryTag, boolean multiple)

而拒絕訊息有兩種方式

  1. basicNack(long deliveryTag, boolean multiple, boolean requeue)

  2. basicReject(long deliveryTag, boolean requeue)

basicNack和basicReject的區別只有一個,basicNack支援批量拒絕

deliveryTag和multiple引數前面已經說過。

requeue=true: 訊息會被再次傳送到佇列中

requeue=false: 訊息會被直接丟失

在這裡插入圖片描述
在這裡插入圖片描述

chapter_6: 失敗通知

chapter_6到chapter_10主要簡述了訊息釋出時的權衡

在這裡插入圖片描述
在這裡插入圖片描述

我們最常用的就是失敗通知和釋出者確認

當訊息不能被路由到某個queue時,我們如何獲取到不能正確路由的訊息呢?

  1. 在傳送訊息時設定mandatory為true
  2. 生產者可以通過呼叫channel.addReturnListener來新增ReturnListener監聽器獲取沒有被路由到佇列中的訊息

mandatory是channel.basicPublish()方法中的引數

mandatory=true: 交換器無法根據路由鍵找到一個符合條件的佇列,那麼RabbitMQ會呼叫Basic.Return命令將訊息返回給生產者

mandatory=false: 出現上述情形,則訊息直接被丟棄

chapter_7: 釋出者確認

當訊息被髮送後,訊息到底有沒有到達exchange呢?預設情況下生產者是不知道訊息有沒有到達exchange

RabbitMQ針對這個問題,提供了兩種解決方式

  1. 事務(後面會講到)
  2. 釋出者確認(publisher confirm)

而釋出者確認有三種程式設計方式

  1. 普通confirm模式:每傳送一條訊息後,呼叫waitForConfirms()方法,等待伺服器端confirm。實際上是一種序列confirm了。
  2. 批量confirm模式:每傳送一批訊息後,呼叫waitForConfirms()方法,等待伺服器端confirm。
  3. 非同步confirm模式:提供一個回撥方法,服務端confirm了一條或者多條訊息後Client端會回撥這個方法。

非同步confirm模式的效能最高,因此經常使用,我想把這個分享的細一下

channel.addConfirmListener(new ConfirmListener() {
	@Override
	public void handleAck(long deliveryTag, boolean multiple) throws IOException {
		log.info("handleAck, deliveryTag: {}, multiple: {}", deliveryTag, multiple);
	}

	@Override
	public void handleNack(long deliveryTag, boolean multiple) throws IOException {
		log.info("handleNack, deliveryTag: {}, multiple: {}", deliveryTag, multiple);
	}
});
複製程式碼

寫過非同步confirm程式碼的小夥伴應該對這段程式碼不陌生,可以看到這裡也有deliveryTag和multiple。但是我要說的是這裡的deliveryTag和multiple和訊息的ack沒有一點關係。

confirmListener中的ack: rabbitmq控制的,用來確認訊息是否到達exchange

訊息的ack: 上面說到可以自動確認,也可以手動確認,用來確認queue中的訊息是否被consumer消費

chapter_8: 備用交換器

生產者在傳送訊息的時候如果不設定 mandatory 引數那麼訊息在未被路由到queue的情況下將會丟失,如果設定了 mandatory 引數,那麼需要新增 ReturnListener 的程式設計邏輯,生產者的程式碼將變得複雜。如果既不想複雜化生產者的程式設計邏輯,又不想訊息丟失,那麼可以使用備用交換器,這樣可以將未被路由到queue的訊息儲存在RabbitMQ 中,在需要的時候去處理這些訊息

chapter_9: 事務

RabbitMQ中與事務機制相關的方法有3個

方法 解釋
channel.txSelect() 將當前的通道設定成事務模式
channel.txCommit() 提交事務
channel.txRollback() 回滾事務

訊息成功被髮送到RabbitMQ的exchange上,事務才能提交成功,否則便可在捕獲異常之後進行事務回滾,與此同時可以進行訊息重發 因為事務會榨乾RabbitMQ的效能,所以一般使用釋出者確認代替事務

chapter_10: 訊息持久化

訊息做持久化,只需要將訊息屬性的delivery-mode設定為2即可

RabbitMQ給我們封裝了這個屬性,即MessageProperties.PERSISTENT_TEXT_PLAIN, 詳細使用可以參考github的程式碼

當我們想做訊息的持久化時,最好同時設定佇列和訊息的持久化,因為只設定佇列的持久化,重啟之後訊息會丟失。只設定佇列的持久化,重啟後佇列消失,繼而訊息也丟失

chapter_11: 死信佇列

DLX,全稱為Dead-Letter-Exchange,稱之為死信交換器。當一個訊息在佇列中變成死信(dead message)之後,它能被重新傳送到另一個交換器中,這個交換器就是DLX,繫結DLX的佇列就稱之為死信佇列。 DLX也是一個正常的交換器,和一般的交換器沒有區別,實際上就是設定某個佇列的屬性

訊息變成死信一般是由於以下幾種情況

  1. 訊息被拒絕(Basic.Reject/Basic.Nack)且不重新投遞(requeue=false)
  2. 訊息過期
  3. 佇列達到最大長度

死信交換器和備用交換器的區別

備用交換器: 1.訊息無法路由時轉到備用交換器 2.備用交換器是在宣告主交換器的時候定義的

死信交換器: 1.訊息已經到達佇列,但是被消費者拒絕等的訊息會轉到死信交換器。2.死信交換器是在宣告佇列的時候定義的

chapter_12: 流量控制(服務質量保證)

qos即服務端限流,qos對於拉模式的消費方式無效

使用qos只要進行如下2個步驟即可

  1. autoAck設定為false(autoAck=true的時候不生效)

  2. 呼叫basicConsume方法前先呼叫basicQos方法,這個方法有3個引數

basicQos(int prefetchSize, int prefetchCount, boolean global)

引數名 含義
prefetchSize 批量取的訊息的總大小,0為不限制
prefetchCount 消費完prefetchCount條(prefetchCount條訊息被ack)才再次推送
global global為true表示對channel進行限制,否則對每個消費者進行限制,因為一個channel允許有多個消費者

為什麼要使用qos?

  1. 提高服務穩定性。假設消費端有一段時間不可用,導致佇列中有上萬條未處理的訊息,如果開啟客戶端, 巨量的訊息推送過來,可能會導致消費端變卡,也有可能直接不可用,所以服務端限流很重要

  2. 提高吞吐量。當佇列有多個消費者時,佇列收到的訊息以輪詢的方式傳送給消費者。但由於機器效能等的原因,每個消費者的消費能力不一樣, 這就會導致一些消費者處理完了消費的訊息,而另一些則還堆積了一些訊息,會造成整體應用吞吐量的下降 在這裡插入圖片描述

springboot-rabbitmq(springboot整合rabbitmq)

未完待續

聯絡我

email: erlie139@gmail.com

歡迎大家和我交流,關注公眾號Java識堂獲取我的聯絡方式

歡迎fork和star
歡迎fork和star


相關文章