RabbitMQ延遲消息的延遲極是多少

RabbitMQ延遲消息的延遲極是多少，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細(xì)講解，有這方面需求的人可以來學(xué)習(xí)下，希望你能有所收獲。

問題定位

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

對之前的延遲消息使用樣例（文末的Git倉庫中可以獲取完整代碼）接口做一下微改，增加了一個請求參數(shù)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";
}

然后嘗試發(fā)起了兩個請求：

請求1：延遲5000毫秒。消息發(fā)送到MQ之后確實延遲了5秒之后才得到了消費，沒有任何問題。

curl localhost:8080/sendMessage?message=hello&delay=5000

請求2：延遲1年（31536000000毫秒）。消息發(fā)送到MQ之后馬上就被消費者消費了，完全沒有延遲效果。

curl localhost:8080/sendMessage?message=hello&delay=31536000000

問題小結(jié)

在明確了問題原因之后，需要對該功能的時候做一些明確的限定（延遲時間的極限），以避免再次出現(xiàn)類似的問題。深入探索下去，這里的失敗主要與消息的過期時間（TTL）有直接的關(guān)系。在RabbitMQ中，消息的過期時間必須是非負(fù) 32 位整數(shù)，即：0 <= n <= 2^32-1，以毫秒為單位。 其中，2^32-1 = 4294967295。

這里我們可以嘗試下面兩個請求，分別設(shè)置延遲時間為4294967295何4294967296：

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

可以發(fā)現(xiàn)，當(dāng)延遲時間為4294967295毫秒的時候，延遲消息工作正常；當(dāng)延遲時間為4294967296毫秒的時候，消息被直接消費，沒有延遲效果。

所以，我們在使用RabbitMQ的延遲消息功能時候，必須注意它的延遲極限是4294967295毫秒。如果你的業(yè)務(wù)需求會超過這個臨界值，就必須避開這個坑，采用其他方法來實現(xiàn)需要延遲或者定時執(zhí)行的任務(wù)了。

看完上述內(nèi)容是否對您有幫助呢？如果還想對相關(guān)知識有進(jìn)一步的了解或閱讀更多相關(guān)文章，請關(guān)注億速云行業(yè)資訊頻道，感謝您對億速云的支持。