RabbitMQ延遲訊息的延遲極限是多少?

2022-01-10 22:31:02 字數 1297 閱讀 6004

之前在寫spring cloud stream專題內容的時候,特地介紹了一下如何使用rabbitmq的延遲訊息來實現定時任務。最近正好因為開發碰到了使用過程中發現,延遲訊息沒有效果,訊息直接就被消費了的情況。因此就繼續深入研究了一下問題原因,在此記錄下來,給碰到類似問題的童鞋們參考。

因為不是所有的訊息都出現了沒有延遲訊息效果的因素,通過有問題的訊息特徵,大致猜測可能是延遲時間過長導致了訊息延遲失敗。為了驗證這個原因,先拿之前文章中的例子,來測試一下延遲時間是否與問題直接相關。

public string messagewithmq(@requestparam string message, @requestparam long delay)

然後嘗試發起了兩個請求:

請求1:延遲5000毫秒。訊息傳送到mq之後確實延遲了5秒之後才得到了消費,沒有任何問題。

curl localhost:8080/sendmessage?message=hello&delay=5000
請求2:延遲1年(31536000000毫秒)。訊息傳送到mq之後馬上就被消費者消費了,完全沒有延遲效果。

curl localhost:8080/sendmessage?message=hello&delay=31536000000
在明確了問題原因之後,需要對該功能的時候做一些明確的限定(延遲時間的極限),以避免再次出現類似的問題。深入探索下去,這裡的失敗主要與訊息的過期時間(ttl)有直接的關係。在rabbitmq中,訊息的過期時間必須是非負 32 位整數,即:0 <= n <= 2^32-1,以毫秒為單位。 其中,2^32-1 = 4294967295。

這裡我們可以嘗試下面兩個請求,分別設定延遲時間為4294967295何4294967296:

curl localhost:8080/sendmessage?message=hello&delay=4294967295

curl localhost:8080/sendmessage?message=hello&delay=4294967296

可以發現,當延遲時間為4294967295毫秒的時候,延遲訊息工作正常;當延遲時間為4294967296毫秒的時候,訊息被直接消費,沒有延遲效果。

所以,我們在使用rabbitmq的延遲訊息功能時候,必須注意它的延遲極限是4294967295毫秒。如果你的業務需求會超過這個臨界值,就必須避開這個坑,採用其他方法來實現需要延遲或者定時執行的任務了。

如果您對這些感興趣,歡迎star、follow、收藏、**給予支援!

rabbitmq延遲訊息

使用rabbitmq來實現延遲訊息必須先了解rabbitmq的兩個概念 訊息的ttl和死信exchange,通過這兩者的組合來實現上述需求。訊息的ttl就是訊息的存活時間。rabbitmq可以對佇列和訊息分別設定ttl。對佇列設定就是佇列沒有消費者連著的保留時間,也可以對每乙個單獨的訊息做單獨的設定...

Rabbitmq延遲佇列

建立乙個自定義列表 如何建立乙個註腳 注釋也是必不可少的 katex數學公式 新的甘特圖功能,豐富你的文章 uml 圖表 flowchart流程圖 匯出與匯入 你好!這是你第一次使用markdown編輯器所展示的歡迎頁。如果你想學習如何使用markdown編輯器,可以仔細閱讀這篇文章,了解一下mar...

RabbitMQ 延遲佇列

rabbitmq實現延遲佇列一 在佇列上設定ttl publish delaysync.exchange delay.5m.queue 延遲佇列 delay.exchange test.queue 正常佇列 consumer 延遲佇列start mapmap new hashmap map.put ...