国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

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

stormzhang / 3363人閱讀

摘要：問題定位因為不是所有的消息都出現(xiàn)了沒有延遲消息效果的因素，通過有問題的消息特征，大致猜測可能是延遲時間過長導(dǎo)致了消息延遲失敗。所以，我們在使用的延遲消息功能時候，必須注意它的延遲極限是毫秒。

之前在寫Spring Cloud Stream專題內(nèi)容的時候，特地介紹了一下如何使用RabbitMQ的延遲消息來實現(xiàn)定時任務(wù)。最近正好因為開發(fā)碰到了使用過程中發(fā)現(xiàn)，延遲消息沒有效果，消息直接就被消費了的情況。因此就繼續(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ù)了。

代碼示例

本文示例讀者可以通過查看下面?zhèn)}庫的中的stream-delayed-message項目：

Github: https://github.com/dyc87112/S...

Gitee: https://gitee.com/didispace/S...

如果您對這些感興趣，歡迎star、follow、收藏、轉(zhuǎn)發(fā)給予支持！

歡迎關(guān)注我的公眾號：程序猿DD，獲得獨家整理的學(xué)習(xí)資源和日常干貨推送。如果您對我的專題內(nèi)容感興趣，也可以關(guān)注我的博客：didispace.com

文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/75551.html

相關(guān)文章

  • Spring Cloud Stream 使用延遲消息實現(xiàn)定時任務(wù)（RabbitMQ）

    摘要：然而實際業(yè)務(wù)中還存在另外一種定時任務(wù)，它可能需要一些觸發(fā)條件才開始定時，比如編寫博文時候，設(shè)置小時之后發(fā)送。在消息監(jiān)聽類中，對通道定義了，這里會對延遲消息做具體的邏輯。由于消息的消費是延遲的，從而變相實現(xiàn)了從消息發(fā)送那一刻起開始的定時任務(wù)。 應(yīng)用場景 我們在使用一些開源調(diào)度系統(tǒng)（比如：elastic-job等）的時候，對于任務(wù)的執(zhí)行時間通常都是有規(guī)律性的，可能是每隔半小時執(zhí)行一次，或者...

    honhon 評論0 收藏0

  • rabbitmq延遲消息示例

    摘要：官方插件僅支持版本中支持。使用過程聲明消息交換機實現(xiàn)實現(xiàn)消息發(fā)送實現(xiàn)實現(xiàn) 官方插件僅支持>=3.6.x 版本中支持。 本文描述的消息延遲機制采用官方推薦的插件rabbitmq-delayed-message-exchange，如精通rabbitmq和編程，請自行查看官方文檔，描述更加詳盡： github Rabbitmq插件列表 安裝 需要在集群每臺機器中安裝由于rabbitmq并...

    RyanQ 評論0 收藏0

  • 一起來學(xué)SpringBoot | 第十三篇：RabbitMQ延遲隊列

    摘要：另一種就是用中的位于包下，本質(zhì)是由和實現(xiàn)的阻塞優(yōu)先級隊列。表明了一條消息可在隊列中存活的最大時間。當(dāng)某條消息被設(shè)置了或者當(dāng)某條消息進入了設(shè)置了的隊列時，這條消息會在時間后死亡成為。 SpringBoot 是為了簡化 Spring 應(yīng)用的創(chuàng)建、運行、調(diào)試、部署等一系列問題而誕生的產(chǎn)物，自動裝配的特性讓我們可以更好的關(guān)注業(yè)務(wù)本身而不是外部的XML配置，我們只需遵循規(guī)范，引入相關(guān)的依賴就可...

    selfimpr 評論0 收藏0

  • Rabbitmq基礎(chǔ)組件架構(gòu)設(shè)計

    摘要：基礎(chǔ)組件架構(gòu)設(shè)計基礎(chǔ)組件封裝設(shè)計迅速消息發(fā)送支持迅速消息發(fā)送模式，在一些日志收集統(tǒng)計分析等需求下可以保證高性能，高吞吐量。基礎(chǔ)組件封裝設(shè)計事務(wù)消息發(fā)送支持事務(wù)消息，且保障可靠性投遞，在金融行業(yè)單筆大金額操作時會有此類需求。 Rabbitmq基礎(chǔ)組件架構(gòu)設(shè)計 基礎(chǔ)組件封裝設(shè)計 - 迅速消息發(fā)送支持迅速消息發(fā)送模式，在一些日志收集、統(tǒng)計分析等需求下可以保證高性能，高吞吐量。 基礎(chǔ)組件封...

    Steve_Wang_ 評論0 收藏0

發(fā)表評論

0條評論

最新活動
閱讀需要支付1元查看
<