本來想帶過一下rabbit整合spring和spring-boot,我看網上很多相關檔案,就沒什么必要了,就來總結一下一些高級特性給自己看看,本章主要以理論為主,至于代碼和使用,我在git上放了一套簡單易懂的 例程,可以下載下來,在advance(高級)中,有延時佇列可供參考,如過需要其學習rabbitMq其他簡單使用可以閱讀 RabbitMq (一)理論篇部分RabbitMQ(二)實踐篇
文章目錄
- 前言
- 一、訊息的可靠性傳遞
- 二、訊息的可靠性接收
- 三、消費端限流
- 四、TTL
- 五、死信佇列
- 六、延時佇列
- 七、冪等性保障
前言
一、訊息的可靠性傳遞
在使用RabbitMQ的時候,為了確保訊息抵達Broker,Rabbit提供了兩種方式供用戶來控制訊息投遞的可靠性模式
- confirm 確認模式
- return 退回模式
RabbitMQ訊息的整個投遞程序:

- confirm 是判斷訊息是否被 exchange 收到,
- return 是訊息被 exchange 收到,但是沒有佇列可以投遞,
使用步驟大體是模式開啟,寫一下回呼函式,做法不同的架構寫的不太一樣,但意思都是一樣的,如果你發現你寫的監聽不起作用,八成就是模式沒開啟,

二、訊息的可靠性接收
上面講的可靠性傳遞,只是確定到了queue,那還需要確定訊息到達消費端,
有三種確認方式:
- 自動確認 : acknowledge = “none”
訊息一旦被Consumer收到,則自動確認簽收,并將相應的message從rabbitmq的訊息快取中移除, - 手動確認 : acknowledge = “manual”
實際業務處理可能會出現例外,可以設定手動簽收,如果正常處理chanel.basicAck()正常簽收,若發生例外chanel.basicNack()拒絕簽收,讓訊息重新發送, - 根據例外情況確認 : acknowledge = “auto”
三、消費端限流
如果請求瞬間增多,超過最大處理請求,會導致系統奔潰,加以限制,讓系統慢慢處理,就可以緩解請求突增的情況,

配置

四、TTL
TTL全稱Time To Live(存活時間、過期時間),當訊息到達存活時間后,還沒有被消費,會自動被洗掉,

- 可以對訊息設定時間,也可以對整個佇列設定時間
- 設定佇列過期時間引數:x-message-ttl,單位ms,會對整個佇列生效,
- 設定訊息過期使用引數:expriration,單位ms,當該訊息在佇列頭部時,會單獨判斷該訊息是否過期,
- 如果兩者都設定了,則以時間較短的為準,
五、死信佇列
DLX(dead letter exchange 死信交換機),當一個訊息成為 dead message 后,可被重新發送到另一交換機,這個交換機就是DLX

什么情況下訊息會成為死信:
- 佇列訊息長度達到限制
- 消費者拒絕消費訊息,basicNack/basicReject,并且不把訊息重新放入原目標佇列,requeue=false
- 原佇列存在訊息過期設定,訊息到達超時時間,未被消費;
六、延時佇列
訊息進入佇列后不會立即被消費 ,等待達到時間后被消費,很可惜,RabbitMQ沒有提供延時佇列功能,但是可以使用TTL+死信佇列組合實作延時佇列效果

七、冪等性保障
一次或多次請求某一個資源,對于資源本身應該具有同一個效果,在MQ中,指消費同一條訊息多次,得到消費該訊息一次相同效果,
通過version版本控制

轉載請註明出處,本文鏈接:https://www.uj5u.com/qita/298903.html
標籤:其他
上一篇:Linux網路配置
