後で拒否されたメッセージを再解析する方法いくつかの外部の問題により、basic.rejectでrequeue = trueのメッセージを再キューする必要があります。RabbitMQ
しかし、短時間でもう一度失敗する可能性があるので、すぐに消費する必要はありません。私がそれを連続して再クエリーすると、無限ループと再クエリーが発生する可能性があります。
だから私は、後でそれを消費する必要があり、1分後に言って、
そして私は、私はそれを再キューイング止めるだけにそれを拒否することができるようにメッセージが再キューイングされている回数を知る必要がありますそれが消費されないと宣言する。
PS：Javaクライアントを使用しています。
最初のものはCeleryによって選択された一方（ブローカーとしてのRabbitMQを使用することができるPythonのプロデューサ/コンシューマライブラリ）である指すように、複数の解決策があります。メッセージの中に、タスクを実行するタイムスタンプを追加します。あなたの消費者がメッセージを受け取ったら、それを確認せずにタイムスタンプをチェックしてください。タイムスタンプに達するとすぐに、作業者はタスクを実行できます。 （作業者は待機するのではなく、他の作業を続けることができます）
この手法にはいくつかの欠点があります。チャネルあたりのQoSを任意の値に増やす必要があります。そして、あなたの労働者が既に長時間実行されている作業に取り組んでいる場合、最初のタスクが終了するまで、遅れたタスクは実行されません。
2番目の手法はRabbitMQのみであり、はるかに優雅です。 dead-letter exchangesとMessages TTLを利用しています。あなたは誰によっても消費されない新しいキューを作成します。このキューには、メッセージをコンシューマキューに転送するデッドレター交換があります。メッセージを延期したい場合は、コンシューマキューからメッセージを受け取って（または再キューに入れずに）拒否し、メッセージを遅延時間（例えば1分後）に等しいTTLでデッドレターキューにコピーします。 （大まかに）TTLの終わりに、拒否されたメッセージは再び魔法のように消費者キューに到着し、消費準備が整います。 RabbitMQチームはまたDelayed Message Pluginを作成しました（このプラグインはexperimental yet fairly stable and potential suitable for production use as long as the user is aware of its limitationsとマークされており、フェイルオーバーの場合のスケーラビリティと信頼性の点で重大な制限がありますので、本番環境で本当に使用したいのか、手動の方法で、キューごとに1つのTTLに制限されます）。
ポイント2は、あなたのメッセージにカウンターを置き、アプリ内でこれを処理するだけです。このカウンターをヘッダーに入れるか、または本文に直接入れるかを選択できます。
2番目の質問について。メッセージ自体にカウンタを追加することができます。 – talex