RabbitMQ遅延メッセージの遅延限界はいくらですか?

前に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";
}

2つのリクエストが開始されました.
要求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では、メッセージの有効期限は、ミリ秒単位で0<=n<=2^32−1の非負の32ビット整数でなければならない.ここで、2^32-1=4294967295です.
ここでは、4294967295何4294967296に遅延時間を設定する2つのリクエストを試してみましょう.

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

遅延時間が4294967295ミリ秒のとき、遅延メッセージは正常に動作することが分かった.遅延時間が4294967296ミリ秒の場合、メッセージは直接消費され、遅延効果はない.
したがって,RabbitMQの遅延メッセージ機能を用いる場合,その遅延限界は4294967296ミリ秒であることに注意しなければならない.ビジネスニーズがこの臨界値を超える場合は、このピットを避け、遅延やタイミングで実行するタスクを実現するために他の方法を採用する必要があります.
コードの例
この例では、次の倉庫の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、コレクション、転送を歓迎します.
私の公衆番号に注目することを歓迎します:プログラム猿DD、独占的に整理した学習資源と日常の乾物のプッシュを獲得します.もしあなたが私のテーマの内容に興味があれば、私のブログにも注目することができます:didispace.com