Azure トピックがあり、トピックに追加されるタイプ X のイベントごとに、そのイベントを 1 つの場所に記録する 1 つのサブスクライバーが必要であり、そのトピック メッセージに対して実際に何らかの処理を行う別のサブスクライバーが必要です。
監査またはサブスクライバーの処理の失敗を数分間処理し、トピック メッセージを見逃さず、データ破損のシナリオを作成するための正しい設計は何ですか?
各インスタンスの 3 つのバージョンを実行できた場合、3 つすべてが同時にダウンする可能性はほとんどありませんが、それは完璧なシナリオではありません。これには他にどのようなオプションがありますか? API の一部として不足しているものはありますか?
あなたが解決しようとしている失敗を理解していないかもしれません。あなたのシナリオを正しく理解していれば、監査サブスクリプションと処理サブスクリプションの両方がサブスクライブされており、「イベント トピック」になっています。これは、監査用と処理用の 2 つの論理コンシューマーがあることを意味します (各コンシューマーは、スループットと冗長性のために同じサブスクリプションから読み取る複数のインスタンスを持つことができるため、論理的と言えます)。
サブスクリプション クライアントの受信モードとして PeekLock (デフォルト) を使用している場合、監査メッセージの記録中またはイベントの処理中にコンシューマーに障害または例外が発生した場合、メッセージは最終的に再表示され、別のコンシューマーによって処理されます。実例。これは、例外のために Complete が呼び出されなかったことを前提としています。理論的には、監査および処理コンシューマーがべき等操作を行っている場合、コンシューマーが失敗した場合でも、オンラインに戻ったときに追いつくことができ、メッセージが見逃されることはありません。上記で提案したように、各コンシューマーの複数のインスタンスを実行しても、これは変わりません。各コンシューマの複数のインスタンスを実行すると、ダウンタイムの可能性が減りますが、そうすべきです。単一のインスタンス処理を行っている場合でも、メッセージを見逃すことはありません。サブスクリプションは、コンシューマが復旧するまで保持されます。
RecieveAndDelete 受信モードを使用した場合、メッセージが失われる可能性があります。これは、 Service Bus Brokered Messaging を使用したパフォーマンス向上のためのベスト プラクティスに関する優れた記事です。これを読んでください。
監査および処理操作がどの程度リソースを集中的に使用するかに基づいて、展開にはあらゆる種類のオプションがあります。ペアとして異なるスレッドで監査メッセージと処理メッセージの両方を処理し、複数のインスタンスをデプロイするワーカー ロールまたはプロセスを使用できます。これは、各インスタンスが両方のタイプのメッセージを処理できることを意味しますが、マシンの 1 つがダウンしても、実行中の別のインスタンスが処理を続行できるという冗長性があります。
配信不能メッセージ (有害なメッセージなど) と、それらのメッセージが処理されていないか、または完全に処理されていないかどうかを確認する必要があります。
さて、あなたはデータの破損について言及しているので、監査ログが書き込まれる可能性を意味していると思いますが、実際のイベントは処理に失敗します. これはもう少しトリッキーです。これらは、結合しようとしている 2 つの異なる操作です。簡単な答えは、これが同期しなくなることを保証できないということです。これらの操作の両方にまたがるトランザクションはありません (また、分散システムに存在することは望ましくありません)。監査は、操作が実際に完了したということではなく、操作を実行する意図と考えてください。メッセージがシステムに提供されたからといって、処理が正常に完了するとは限りません。処理が発生すると、操作が実際に完了したことをログに記録できます。または、別のオーディターが記録するようにメッセージを送信する場合もあります。これにより、システムで分析するためのより良いメトリックが得られます。つまり、要求された操作の数と実際に完了した操作の数です。このメトリックを一定期間表示すると、システムの実際の成功したスループットを提供できます。