3

私は最近、メッセージング システムについて調べていて、具体的にはRabbitMQとNServiceBusの両方を調べました。私が理解しているように、メッセージが何らかの理由で失敗した場合、すぐに何度も再試行されます。両方のシステムは、後で、たとえば 5 秒後に再試行する可能性を提供します。5 秒が経過すると、メッセージが何度も再送信されます。

ドメイン駆動設計の実装(p.502)で Vaughn Vernon を引用します。

これを処理するもう 1 つの方法は、おそらく Capped Exponential Back-off を使用して、成功するまで送信を再試行することです。RabbitMQ の場合、再試行はかなりの時間失敗する可能性があります。したがって、メッセージの NAK と再試行を組み合わせて使用​​することが最善の方法です。それでも、プロセスが 5 分ごとに 3 回再試行する場合は、これで十分です。

NServiceBus の場合、これは第 2 レベルの再試行と呼ばれ、再試行が発生すると複数回発生します。

なぜ複数回発生する必要があるのですか？5 分ごとに再試行しないのはなぜですか? 5 分後の最初の再試行が失敗し、おそらく数ミリ秒後の 2 回目の再試行が成功する可能性はどれくらいですか?

また、何らかの構成のために必要がない場合(そうですか?)、私が見つけたすべての例で複数回の再試行が行われるのはなぜですか?

4

2 に答える 2

5

私のバックグラウンドは NServiceBus であるため、私の答えはそれらの用語で表現される可能性があります。

最初のレベルの再試行は、非常に一時的なエラーに最適です。デッドロックはこの完璧な例です。データベースを変更しようとすると、トランザクションがデッドロックの犠牲者として選択されます。このような場合は、最初のレベルの再試行が最適です。ほとんどの場合、最初のレベルの再試行は 1 回で十分です。データベースで多くの競合が発生している場合は、2 回または 3 回の再試行で十分です。

第 2 レベルの再試行は、一時的なエラーが少ない場合に使用します。Web サービスが 10 秒間ダウンしている場合や、フェールオーバー クラスター内の SQL Server データベースが 30 ～ 60 秒かかる場合があることを考えてみてください。数ミリ秒後に再試行しても効果はありませんが、10 秒、20 秒、30 秒後にはうまくいく可能性があります。

ただし、問題の核心は、5 回の最初のレベルの再試行とその後の遅延の後です。なぜ追加の遅延の前に 5 回再試行するのでしょうか?

まず、最初の第 2 レベルの再試行で、デッドロックまたはその他の非常に一時的なエラーが発生する可能性があります。結局のところ、通常、目標はシステムをできるだけ遅くすることではないため、問題が本当に一時的なものである場合は、再試行する前に追加の遅延を待つ必要がないことが望ましいでしょう。もちろん、問題がどれほど一時的であるかをインフラストラクチャが知る方法はありません。

2 番目の理由は、それらがすべて同じであれば構成が簡単だからです。X レベルの再試行とレベルごとの Y 回の試行 = X*Y の合計試行と構成ファイル内の 2 つの数値のみ。NServiceBus では、これらの 2 つの値とバックオフ時間の範囲なので、構成は次のようになります。

<SecondLevelRetriesConfigEnabled="true" TimeIncrease ="00:00:10" NumberOfRetries="3" />
<TransportConfig MaxRetries="3" />

それはかなり簡単です。3回試してください。10 秒待ちます。3回試してください。20 秒待ちます。3回試してください。30 秒待ちます。3回試してください。その後、完了し、エラー キューに移動します。

レベルごとに異なる値を構成するには、はるかに複雑な構成ストーリーが必要になります。

于 2013-06-21T13:53:08.690 に答える
3

ネットワークやデータベースのロックなどの迅速な問題を補うために、第 1 レベルの再試行が存在します。これは NSB で設定できるので、不要な場合はオフにできます。第 2 レベルの再試行は、より長い停止を補うためのものです。たとえば、SLR を使用して、毎晩同時にリサイクルするデータベースを補正します。

OOTB 機能を使用すると、SLR 間の期間が長くなります。これは、前回動作しなかった場合、修正にさらに時間が必要になると想定しているためです。オーバーライド可能な再試行ポリシーが存在するため、SLR の動作を変更できます。

NSB では、FLR が常に最初に来て、FLR の後でトランザクションがまだ失敗しない限り、SLR は機能しません。さらに、SLR を完全に無効にして、追加機能を持つ独自のカスタム Fault Manager を構築できます。問題の特定のサブセットを解決する唯一の方法であるため、問題を有人ヘルプ デスクに送信する Fault Manager を使用するプロセスがあります。

于 2013-06-21T13:51:15.997 に答える