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

程式猿DD發表於2019-07-23
MQ

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

問題定位

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

對之前的延遲訊息使用樣例（文末的Git倉庫中可以獲取完整程式碼）介面做一下微改，增加了一個請求引數delay來控制延遲時間：

@GetMapping("/sendMessage")
public String messageWithMQ(@RequestParam String message, @RequestParam Long delay) {
    log.info("Send: " + message);
    testTopic.output().send(MessageBuilder.withPayload(message).setHeader("x-delay", delay).build());
    return "ok";
}

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

請求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毫秒。如果你的業務需求會超過這個臨界值，就必須避開這個坑，採用其他方法來實現需要延遲或者定時執行的任務了。

程式碼示例

本文示例讀者可以通過檢視下面倉庫的中的stream-delayed-message專案：

  • Github: https://github.com/dyc87112/SpringCloud-Learning/tree/master/4-Finchley
  • Gitee: https://gitee.com/didispace/SpringCloud-Learning/tree/master/4-Finchley

如果您對這些感興趣，歡迎star、follow、收藏、轉發給予支援！

相關文章