問題タブ [azure-servicebus-topics]

次の要件があります

トピック/キューに発行されたメッセージ

複数のコンシューマがトピック/キューにサブスクライブしています。したがって、私たちの要件は、1 人の消費者だけがメッセージを聞く必要があるということです。つまり、他のコンシューマーは同じメッセージを受け取ることができません。

キューが最適だと思います。しかし、トピックスからそれを達成できるかどうかを確認するようにアーキテクトからアドバイスを受けました。

ですから、トピックや賛否両論を通じてそれを達成できるかどうか、誰か教えてください。

ありがとう。

Nservicebus 4.7.5 と azure サービス バスをトランスポートとして使用しています。私のエンドポイントは単なるイベントのサブスクライバーであり、何も公開しません。イベントを受け取ったエンドポイントは、Azure ストレージを呼び出して CRUD を実行します。

Azure Storage データセンターが一時的にオフラインになると、エンドポイントは引き続き実行され、メッセージはデッド レター キューに入れられます。

ストレージに一時的な問題が発生したときにメッセージを消費するエンドポイントを停止する方法を探しているため、メッセージが配信不能になるのを防ぐことができます。

一連のキューに対してデッド レタリングが有効になっています。ただし、法的義務により、特定のメッセージをデッド レター キューから削除するか、TTL 後にデッド レターをまったく送信しないようにする必要があります。名前空間には 10 万を超えるサブスクリプションがあるため、デッド レター キューごとに受信者を作成して削除するオプションを除外しています。

トピックのデッドレターが有効になっている場合でも、特定のメッセージをデッドレターにしない方法はありますか? この要件に対処する他の方法はありますか?

新しいメッセージがトピック/サブスクリプションに追加されたときにトリガーされる Azure 関数を作成したいと考えています。

とりあえず、 ServiceBusQueueTrigger C# テンプレートを使用して Azure 関数を作成し、キュー名を

しかし、私はこの例外を持っています:

Microsoft.ServiceBus: QueueDescription型ではないため、エンティティ 'topic-test/Subscriptions/subscription-test' を取得できません。正しいエンティティ タイプのメソッドを使用していることを確認してください。System.Runtime.Serialization: 行 1 の位置 1762 でエラーが発生しました。名前空間 ' http://schemas.microsoft.com/netservices/2010/10/servicebus/connect ' から要素 'QueueDescription' を予期しています'.. 名前 ' の 'None' が見つかりました'、名前空間 ''. .

Azure 関数はMessagingFactory.CreateMessageReceiverを使用してメッセージ ポンプを初期化していると思いましたが、そうではありませんでした。

今のところ、トピック/サブスクリプションのサポートはありますか?

Azure Service Bus のトピックとサブスクリプションを扱っています。アプリケーション全体で制御メッセージを送信するために使用されています。メッセージ リスナー (サブスクライバー) はワーカー ロールで実行されており、メッセージを取得して要求を処理しています。複数のリスナーが同時に実行されている場合でも、バス内の各メッセージは 1 回だけ取得できます。

Service Bus の使用に問題はありません。ただし、アプリケーションをローカルでデバッグ/テストしているときに、いくつかの問題に直面しています。クラウド用とローカル デバッグ用の 2 つのサービス バスがあります。複数の人がアプリケーションを同時にデバッグしている場合、メッセージはシステムの 1 つだけによって (ランダムに) 選択されます。これは意図された動作ですが、デバッグ中に迷惑になります。

Service Bus にローカル エミュレーターを使用する方法はありますか? 私はいくつかの調査を行いましたが、これに対する信頼できる解決策を見つけることができませんでした。アプリケーションを分離してデバッグする方法はありますか?

現時点で私が取り組んでいることの簡単な要約：

関連するメタデータ/フィルターを使用して、1 つのトピックと N 個のトピックが必要な場合でこれを実行できるかどうかを決定しています。

私はほとんど3個持っています。現場のユニットが接続するソケット サーバー (ワーカー ロール)、Azure Service Bus メッセージング、そして最後に Web アプリ。ユーザーは、Web アプリを介してデバイスに送信されるコマンドをキューに入れることができますが、デバイスがオンラインになるまでメッセージをキューに保持できる必要があり、デバイスはすべてのメッセージを取得します。迷っているところです...

私は当初、キューに入れられたメッセージの Web アプリで 1 から 9999 のトピックを動的に作成する方法に沿って作業していました (作成できるトピックの上限は 10,000 であるため、シリアルの最後の 4 文字を使用します)。その後、メタデータ内にデバイスの完全なシリアルが含まれます。このようにして、デバイスがソケット サーバーに接続するときに、特定のルールで N 個のサブスクリプションを作成し、デバイスが切断されたときにそれらをシャットダウンできます。

しかし、トピックを 1 つだけにして、すべてのロジックをメタデータ内に配置できるかどうか疑問に思っています。

私はサービスバスを使用したSQLFiltersに非常に慣れていないので、どんな助けでも大歓迎です:)

有効期限が切れていないサブスクリプションを持つクライアント アプリケーションのみがサービス バスからメッセージを受信できるシナリオで、サービス バスをどのように使用しますか? ユーザーがメッセージのサブスクリプションを一定期間購入できる有料サービスがあるとします。そのため、サービス バスは、選択したクライアント グループ (アクティブなサブスクリプションを持つクライアント) にのみ新しいメッセージを送信する必要があります。このための承認がクライアント アプリではなくサーバー側で行われる場合は、はるかに望ましいことです。サービス バス モデル (キュー、トピック、リレー) を見ると、このユース ケースに適合するものはないようです。

これを実装するために私が考えていた 1 つの方法は、SAS キーを毎日変更し、クライアント アプリケーションに Web API から SAS キーをクエリさせることでした。そのため、有効なサブスクリプションを持つクライアントのみが、SAS を更新してサービス バスから受け取ることができます。ただし、API を使用して SAS を変更できるかどうかはわかりません。

Azure Service Bus でこの種のシナリオをより適切にサポートする方法はありますか? または、それを実装するためのより良い方法を考えられますか?