デッドレターのメカニズムを使用するには、RabbitMqを介してすべてのサードパーティのAPI呼び出しをルーティングすることは理にかなっていますか？

Question

たとえば、Googleの情報の一部をサードパーティのAPIに渡したいとします。このAPIがダウンするとネットワークのエラーが発生することはありません。そこで、我々は2つの選択肢があります。要求の

1. ログインの失敗は、このAPIに押され、いくつかのスケジュールの仕事を介してそれらをプッシュしようとしている - 問題は、これらの要求の一部が原因ダウンしているAPIに失敗した場合、我々は必要なものですこれらの失敗したリクエストも再発行してください。これがオンになります。
2. Rabbitmqのデッドレターメカニズムのようなものを使用してください。失敗したリクエストに対して再試行の仕組みを使用できますが、メンテナンスが増え、複数のデッドレターの再試行があっても失敗した場合はどうなりますか？

このような第3のAPIプロセスをどのように処理し、失敗したリクエストを再度プッシュする必要がありますか？

Answer 1

したがって、RabbitMQ dead-letteringは、negative acknowledgementと同じではありませんが、関連付けることはできます。

あなたは（私はそれはあなたの説明は非常に抽象的であるcorrectly-理解していることを仮定して）記述されているシナリオは、かなり一般的な状況で、次の一連のイベントによって説明することができます。

1. プロセッサからのメッセージを受け取りキュー
2. プロセッサがメッセージを処理しようとしました
3. プロセッサがメッセージ処理に失敗しました
4. ？

質問は手順4で行うことです。多くのアプリケーションでは、手順4でメッセージを削除します。しかし、RabbitMQでは、この状況で否定応答を使用することができます。これは、メッセージを処理できなかったことをブローカに通知します。ブローカは、メッセージをキューの先頭に戻すことができます。同じプロセッサがメッセージを再度受け取って処理しないようにすることはできません。したがって、エラー状態が一時的な場合（つまりメッセージ自体ではなくプロセッサの問題）に使用する必要があります。

アプリケーションの処理ロジックは、メッセージをキューから取り出して処理しようとするときに決定する必要があります。たとえば、あらかじめ決められた時間待機することは理にかなっているかもしれません。また、サードパーティのAPIをポーリングしてバックアップが取れるまで賢明かもしれません。ここであなたがするのはあなた次第です。

デッドレタリング

メッセージ（basic.nackを）拒否したときに今、あなたはrequeue=falseを指定することにより、RabbitMQのデッド文字かどうかのメッセージを制御することができます。 requeueがfalseの場合、メッセージはデッドレターになります（デッドレターエクスチェンジが設定されていない場合はドロップされます）。

デッドレターのキューはまさにそれです。メッセージが消える場所です。基本的に、通常のプロセッサーをこのキューに接続するのは理にかなってはなりません。なぜなら、定義上、最初にメッセージが処理された理由は処理できないからです。そのため、条件を一時的にする（つまりサーバーがダウンする）場合は、メッセージを再キューし、条件が解決されるまでさらにメッセージの処理を停止します。一方、メッセージに問題がある場合は、すべての手段でデッドレターにしてください。