4

SQL Server Service Broker キューを使用するために Web で見つけたすべての例には、2 つのキューがあるようです。理由がわかりません。すべての例は、これが説明する必要がないほど明白であると想定しているようです。

いくつかのものがキューに書き込まれ、ストアド プロシージャがキューから読み取られてデータベースに挿入されます。なぜ 2 つのキューが必要なのですか?

例: http://www.techrepublic.com/article/use-service-broker-internal-activation-in-sql-server-2005/6156264#

4

2 に答える 2

3

技術的には、アプリケーションで SSB テクノロジを使用して 1 つのキューを使用できます。この場合、このキューには、イニシエーターからの要求メッセージとターゲットからの応答メッセージが混在しています。ストアド プロシージャは、それぞれを区別し、整理し、どの応答がどの要求に対するものであるかを判断するなどのメカニズムを実装する必要があります。また、このキューからメッセージを正確な順序で受信し、それらの一部をスキップしてさらに処理するためにキューに残すことはできないことに注意してください。

あなたのケースでは、Remus Rusanu の答えに従い、データベース テーブルを使用してキューを実装する方が良いでしょうか?

SSB の考え方は単純です。イニシエーターは、ターゲットからの応答メッセージを独自のキューで待機している間に、要求メッセージをターゲットのキューに配置します。それはあなたの場合ですか？いいえの場合、SSB はまったく必要ないのでしょうか?

于 2013-02-02T11:31:44.163 に答える
2

Service Broker は基本的にキューとは関係ありません。Service Broker は、キューイング用ではなく、分散アプリケーションを作成するためのものです。キューは単にサービスのメッセージ ストアであり、1 つのサービスが 1 台のマシンにあり、もう 1 つのサービスが 2 台目のマシンにあります。例では、簡単にするために同じデータベース内の両方のサービスを示している場合がありますが、この例は依然として分散環境での通信に関するものです。

明らかに単一のキューで十分なケースを示す例は、Service Broker を誤って使用しています。これらの例は、テーブルを queue として使用する方法をよりよく示しているはずです。

于 2013-02-01T11:33:03.097 に答える