9

そのため、最近 Azure Service Bus を調査しましたが、無限ループを使用してキュー/サブスクリプションをポーリングする必要があるのか​​、それとも OnMessage コールバック/メッセージ ポンプ機能を使用する必要があるのか​​について、少し混乱しています。より少ない操作を実行してコストを削減するにはどうすればよいでしょうか?

理想的には、操作を無駄にしないようにイベント駆動型システムが必要であり、一般的にははるかに優れたアプローチです。

私の質問は、「イベント駆動型メッセージ ポンプでメッセージを処理する」と定義されている OnMessage を使用して、本当にイベント駆動型ですか?

このページ (QueueClient.OnMessage): https://msdn.microsoft.com/library/azure/microsoft.servicebus.messaging.queueclient.onmessage.aspxを見ると、下部にあるコメントに気付くでしょう。基本的には、Receive() メソッドを呼び出す無限ループのラッパーです。それは私にはあまりイベント駆動型ではないように思えます。

このページ (SubscriptionClient.OnMessage): https://msdn.microsoft.com/en-us/library/azure/dn130336.aspxを見ると、その発言は存在しません。トピック/サブスクリプションとキューで同じですか、それとも実際にはサブスクリプションではイベント駆動型ですが、キューではそうではありませんか?

明らかにそうではないのに、なぜ彼らはそれがイベント駆動型であるとさえ言っているのですか? QueueClient.OnMessage ページの発言に「無限ループ」「すべての受信操作が課金対象イベント」という言葉があるのはちょっと怖いです。

また、どちらの方法でも費用がかかるかどうかについてはあまり心配していません。可能な限り効率的にすることに関心があります。

4

1 に答える 1

5

私は OnMessage を使用したことがありませんが、質問に興味を持ったので、掘り下げました。

私の理解では、OnMessage アプローチは、キューからのメッセージの処理に関する通常の懸念事項の一部をカプセル化して、よりクリーンで簡単な方法を提供し、心配する必要がほとんどないということです。したがって、ポーリングに関するすべての足場を作成する代わりに、「プッシュ型/イベント駆動型」の実装 (メッセージ ポンプ モデル) に集中できます。

したがって、基本的には Receive() を呼び出す単なるループであるという点で正しいです。したがって、デフォルトのタイムアウトでは、ポーリングの数は同じであり、したがって同じコストになります。

私はこれらの参照に出くわしました:

http://fabriccontroller.net/introducing-the-event-driven-message-programming-model-for-the-windows-azure-service-bus/

http://www.flyersoft.net/?p=971 - コメントもチェックしてください。これはあなたと同じ質問をカバーしています。

トピック/サブスクリプションとキューで同じですか、それとも実際にはサブスクリプションではイベント駆動型ですが、キューではそうではありませんか?

私は 100% ではありませんが、私の調査に基づく私の推測では、それは同じであり、ドキュメントが明確でない場合にすぎません。

于 2016-01-28T15:56:56.550 に答える