1

ワークキューと SqlDependency がぴったりだと思う状況がありますが、すべてをつなぎ合わせるのに苦労しています。

1000 個のエンティティがあり、各エンティティを異なる間隔 (つまり、15 分、30 分、または 45 分) で「処理」する必要があるとします。より多くの作業を探すために SQL Server を毎分ポーリングすることなく、作業を複数のプロセスに分割したいと考えています。SqlDependency / クエリ通知に関連する多くの記事を読みましたが、作業をキューに入れる方法と、各プロセスを一連の作業項目に制限する方法がわかりません。

次のような SqlDependency クエリを作成しました。

select f1, f2, etc from dbo.entity where LastRunDt < datediff(minute, 15, @dt)

クエリは 0 の結果で実行されますが、15 分が経過すると、このレコードセットが変更されます (レコードセット内の項目が増えます)。通知は発生しません。この方法ではうまくいかないと思うので、作業項目をキューに入れる方法に行き詰まっています。

また、2 つのプロセスを同じ作業キューにアタッチすると、各プロセスに通知されますが ( select * from dbo.entitySqlDependency クエリを実行してレコードを変更すると)、両方とも同じ作業項目を受け取ります。どのサーバーがオンラインで、どのサーバーがメンテナンスのためにオフラインであるかに応じて、リスナーの数が 2 または 12 になる可能性があるため、使用可能なプロセス間で作業項目を分割する必要があります。

クライアントは C# で記述されます。

既知のパターン、考え、または方向性は非常に高く評価されます。

4

2 に答える 2

1

ある種のメッセージキューが必要なようです。NServiceBusのようないくつかの一般的なミドルウェアパッケージがあります。

トランザクション的かつ高速な方法でSQLServerとうまく統合するServiceBrokerを使用することもできます。

于 2012-07-17T19:02:06.913 に答える
1

ここでクエリ通知を行う必要はありません。ServiceBrokerを直接使用します。

C＃アプリケーションWAITFOR(RECEIVE ...)にステートメントを発行させて、作業タスクを取得します。作業が可能な場合は、を使用してメッセージをキューに入れますSEND。将来の使用をスケジュールするにはBEGIN CONVERSATION TIMER。

さらに、Service Brokerは、内部マネージドストアドプロシージャ（ Service Broker Activationを参照）または外部スタンドアロンアプリケーション（Service Broker External Activatorを参照）として、C＃コードを実際にアクティブ化するのに役立ちます。

于 2012-07-17T19:27:25.317 に答える