29

したがって、シナリオは、SB キューを使用して、他のサービスへの発信コールバックを抑制しているというものです。他のサービスへのコールバックに関する標準的な問題の 1 つは、それらが制御不能な時間ダウンする可能性があることです。ターゲットがダウンしている/応答していないことを検出したと仮定すると、そのメッセージを破棄してキューにすぐに再表示されないようにするための最良のパターンは何ですか?

私が知っている、試した、または検討しているいくつかのアプローチを次に示します。

  • 明らかにBrokeredMessage::Abandon()、メッセージを使用しただけではロックが解除され、キューに戻されます。これは、このシナリオと私が回避しようとしているものにとって明らかに望ましくありません。

  • エラーが発生したという事実を無視して Abandon を呼び出さないと、すぐに表示されなくなりますが、再び表示されるまでの時間を細かく制御することはできず、実装したいと思います減衰再試行戦略。

  • BrokeredMessage::Abandon(IDictionary<string, object>)プロパティを呼び出して何らかの形で更新できるのではないかと思いScheduledEnqueueTimeUTCましたが、これを試してみましたが、メッセージの最初の送信以外にそのプロパティに影響を与える方法はないようです。理にかなっていますが、試してみる価値があると思いました。

  • この状況で使用BrokeredMessage::Complete()するだけで、実際にはプロパティ セットを使用してメッセージの新しいコピーをキューに入れることを検討しました。ScheduledEqueueTimeUTC

最後の箇条書きはややこしすぎるように思えますが、キューの固有の性質を考えると、おそらく正しい答えであるという結論に達しています。不足している Azure SB キュー内でこれを行うためのより良い方法があるかもしれないと考えました。

4

5 に答える 5

1

Receive(TimeSpan)上記の箇条書き 2 で:デフォルトの代わりに、呼び出し時にメッセージの TTL タイムスパンを設定することはできませんReceive()か? 次に、( を呼び出さずに) メッセージを破棄するだけAbandon()で、TTL の期限が切れたときにメッセージがキューに再表示されます。これにより、「x 秒後に再表示する」ように細かく制御することはできませんが、メッセージが再表示されるタイミングを予測できます。

注: ストレージベースのキューを使用すると、非表示タイムアウトを更新できるため、メッセージの再表示をきめ細かく制御できます。

于 2013-04-30T01:29:25.667 に答える
1

少しハッキーに感じますが、私が思いついた解決策は

try 
{
   ...
}
catch (Exception ex)
{
   await Task.Delay(30000);
   throw;
}

このようにして、放棄を許可する前に 30 秒間待機します。構成された回数が経過すると、最終的に配信不能になります。

受信にはAzure Webjobsを使用しています。Task.Delay代わりに使用しThread.Sleepていますが、待機中にスレッドを解放してキューから別のアイテムを処理しているようには見えません (デフォルトでは、Webjobs は 16 を並行して処理します)。

于 2016-07-29T15:41:02.843 に答える
0

私があなたなら、インターネット上にある多くのエンタープライズ統合パターンのページの 1 つを参照して、解決策を探します。基本的には、失敗した場合にメッセージを配信不能キューに連続して送信する再試行が必要です。これらのメッセージは、後で再度キューに入れることができます。これは、要件に応じて手動または自動で行うことができます。

私があなたに送ったページは camel に関連しているため、そのページに記載されているすべての内容が .NET と azure に適用されることに注意してください。あなたが興味を持っているなら、ここにもっと.NETのものがありますhttp://www.eaipatterns.com/

于 2013-04-29T23:14:25.347 に答える