5

クラッシュまたはその他の異常な終了（インスタンスの再起動など）が原因で、キュー、トピック、またはサブスクリプションの読み取りまたは書き込みを行うパブリッシャーまたはサブスクライバーがなくなった場合、そのキュー/トピック/サブスクリプションは事実上孤立していますか？

いくつかのキューを作成してからアプリケーションを終了することで、これをテストしました。それらのキューは、ずっと後もサービスバス上にありました。彼らは永遠にそこにとどまるようです。その振る舞いを望んでいればそれは素晴らしいことですが、この場合はそうではありません。

これらのキュー、トピック、およびサブスクリプションをどのように検出して削除できますか？これらはAzureの制限などにカウントされ、インスタンスが再起動/パッチ適用/クラッシュするたびにこれらの孤立したプロセスを持つことはできません。

質問を明確にするのに役立つ場合、これは、キュー/トピック/サブスクリプションに特別な名前または特別なフィルターがあり、限られた時間のパブリッシャー（1）とサブスクライバー（1）のセットが非常に限られているという独特の状況です。これは、私たちが存続可能性を求めている場合ではありません。これらはインスタンス固有の応答チャネルです。キューとサブスクリプションのどちらを使用するかは重要ではありません。インスタンスがなくなった場合は、そのキュー（またはサブスクリプション）も必要になります。

これは、各Webロールが監視する専用の応答チャネルを持つソリューションの一部です。いつでも、このWebロールには、他のメッセージングチャネル（キュー/トピック）を介して保留中の数十の要求があり、複数のスレッドで応答を待機しています。Webロールが呼び出し元に応答できるように、メッセージを配置したスレッドに戻るための応答が必要です。この状況では、他のスレッドのメッセージを受信するため、マシンに基づいてサブスクリプションを作成するのは適切ではありません。専用の応答チャネルを確立するために各公開スレッドが必要です。そのため、そのチャネル上の唯一のものはそのスレッドの応答です。

サブスクリプション（ある種のインスタンス関連フィルターを使用）を使用してサブスクリプションでロングポーリング受信操作を実行したとしても、Webロールインスタンスが停止すると、そのサブスクリプションは孤立しますよね？

この質問は、次のように要約できます。キュー/トピック/サブスクリプションのパブリッシャーまたはサブスクライバーがこれ以上ない場合、そのサービスは事実上孤立しています。これらの孤児をどのように検出してクリーンアップできますか？

4

5 に答える 5

3

このシナリオでは、キュー/サブスクリプションが本質的に「動的」であることを探しています。これらは、これらのエンティティの現在の明示的なプロビジョニングモデルとは対照的に、使用に基づいて作成および削除されます。Service Busは、作成/削除操作を実行するためのAPIを提供するため、これらをロールOnStart/OnStopイベントに適切にプラグインできます。これらの操作が何らかの理由で失敗した場合、孤立したエンティティが存在します。ここでも、エンティティ名の一意の識別子に基づいて、それらに対してクリーンアップ操作を実行できます。この例はここで見ることができます：http ：//windowsazurecat.com/2011/08/how-to-simplify-scale-inter-role-communication-using-windows-azure-service-bus/

近い将来、キュー/トピック/サブスクリプションにメタデータとクエリ機能を追加して、最後にアクセスされた日時を確認し、クリーンアップを決定できるようにする予定です。

于 2012-09-11T21:55:07.997 に答える
1

Service Busキューは、複数の通信プロトコル、データコントラクト、信頼ドメイン、ネットワーク環境にまたがる可能性のあるアプリケーションまたはアプリケーションコンポーネントを統合するように設計された「ブローカリングメッセージング」インフラストラクチャを使用して構築されます。は、耐久性のあるメッセージングと確実に通信するメカニズムを可能にします。

クライアント（パブリッシャー）がサービスバスキューにメッセージを送信してからクラッシュした場合、コンシューマーがキューからメッセージを読み取るまで、メッセージはキューに保存されます。また、コンシューマーが停止して再起動した場合、キューをポーリングし、待機している作業をすべて取得します（スケールアウトして、複数のコンシューマーにキューから読み取りを行わせてスループットを向上させることができます）。ServiceBusキューを使用すると、次の方法でアプリケーションを分離できます。オンプレミスのMSMQ（または他のキューイングテクノロジー）に類似した耐久性のあるクラウドゲートウェイ。

私が本当に言いたいのは、孤立したキューを取得しないことです。処理する必要のある汚染されたメッセージを取得する可能性があります。このブログ投稿では、サービスバスキューとその容量およびクォータに関する非常に詳細な情報を提供しています。http://msdn.microsoft.com/en-us/library/windowsazure/hh767287.aspxをよりよく理解できる可能性があります

Re：キュー管理。これはVisual Studio（1.7 SDKおよびツール）を介して実行できます。または、キュー管理を容易にするService Bus Explorerと呼ばれる優れたツールがあります：http：//code.msdn.microsoft.com/ windowsazure / Service-Bus-Explorer-f2abca5a

*デフォルトのキューの最大数は10,000であることに注意してください（サービス名前空間ごとに、これはサポート呼び出しを介して増やすことができます）

于 2012-09-09T01:00:34.560 に答える
1

Abhishek Laiが述べたように、孤立した検出機能はサポートされていません。

孤立検出は、複数の方法で外部から実装できます。たとえば、メッセージを送受信するときはいつでも、SQLデータベースのタイムスタンプを更新して、キュー/トロピック/サブスクリプションがまだアクティブであることを示します。このタイムスタンプを使用して、孤立したユーザーを特定できます。

于 2012-09-11T22:26:41.800 に答える
0

プロセスがクラッシュする可能性が非常に高い場合は、キュー内のメッセージ配信に問題が発生しますが、キューは引き続きリクエストを処理できます。Windows Azure Service Busキューを使用したアプリケーションのクラッシュと読み取り不能なメッセージの処理については、次のとおりです。

Service Busは、アプリケーションのエラーやメッセージの処理の問題から適切に回復するのに役立つ機能を提供します。受信者アプリケーションが何らかの理由でメッセージを処理できない場合、受信したメッセージに対して（Completeメソッドではなく）Abandonメソッドを呼び出すことができます。これにより、Service Busはキュー内のメッセージのロックを解除し、同じ消費アプリケーションまたは別の消費アプリケーションのいずれかがメッセージを再度受信できるようにします。

メッセージの処理後、Completeリクエストが発行される前にアプリケーションがクラッシュした場合、メッセージは再起動時にアプリケーションに再配信されます。これは、「少なくとも1回の処理」と呼ばれることがよくあります。つまり、各メッセージは少なくとも1回処理されますが、特定の状況では、同じメッセージが再配信される場合があります。シナリオが重複処理を許容できない場合、アプリケーション開発者は、重複メッセージ配信を処理するためにアプリケーションにロジックを追加する必要があります。これは、多くの場合、メッセージのMessageIdプロパティを使用して実現されます。このプロパティは、配信を試行しても一定のままです。

于 2012-09-09T01:13:18.513 に答える
0

クラッシュやその他の異常な終了（インスタンスの再起動など）が原因で、キューの読み取りまたは書き込みを行うプロセスがなくなった場合、そのキューは事実上孤立していますか？

ブローカーメッセージを介して通信を行うためのキューはありません。すべてのアプリが何らかの理由で停止した場合でも、キューは引き続き存在し、アプリが再び有効になったときに存在します。これは、緩く分離されたアプリケーションの通信チャネルです。請求に関して'メッセージは、請求月中にService Busに送信された、またはサービスバスによって配信されたメッセージの数に基づいて課金されます。'キューが存在するが誰も使用していない場合、課金されません。

いくつかのキューを作成してからアプリケーションを終了することで、これをテストしました。それらのキューは、ずっと後もまだマシン上にありました。

キューの要点は、緩く分離されたアプリケーションのメッセージ配信を保証することです。キューは、Azureでホストされている高可用性（SLA）を備えたエンティティまたはアプリケーションと考えてください。プロデューサー/コンシューマーは停止/再起動でき、キューはAzureでアクティブになります。*「しばらくしてからまだマシン上にある」という言い回しと少し混乱していることに注意してください。キューは実際にはマシン上に存在せず、Azureの指定されたサービスバス名前空間に配置されます。前の回答で指摘したツールを使用して、キューを表示および管理できます。

これらのキューはAzureの制限などにカウントされるため、どのようにしてこれらのキューを検出して削除できますか。

上記のように、デフォルトのキューの最大数は10,000です（サービス名前空間ごとに、これはサポートコールを介して増やすことができます）。キュー管理は、他の回答に記載されているツールを介して実行できます。キューの削除を検討しているのは、プロデューサー/コンシューマーがキューへの書き込みを検討していない場合のみです（つまり、二度とない場合）。もちろん、namespaceManager.QueueExistsを介して、プロデューサー/コンシューマーアプリケーションでキューを作成および削除できます。詳細については、サービスバスキューの使用方法を参照してください。

質問を明確にするのに役立つ場合、これは、キューに特別な名前があり、限られた時間の発行者（1）とサブスクライバー（1）の非常に限られたセットを持つという独特の状況です。

トピックとサブスクリプションを使用する必要があるようです。ServiceBusトピック/サブスクリプションの使用方法。このリンクには、「トピックとサブスクリプションを削除する方法」に関するセクションもあります。有効期間が非常に限られている場合は、トピックの作成/削除をで処理できます。それ以外の場合、アプリでは、このロジックを処理するための個別のキュー/トピック/サブスクリプションのセットアップ/削除スクリプトを使用できます...

于 2012-09-09T20:14:13.870 に答える