2011-01-05 10 views
0

システムの負荷をより適切に制御するために、待ち行列に入れられたジョブをバックグラウンドで順番に(または並列のn個のスレッドで)実行する必要があります。マイクロソフトでのタスクのバックグラウンド処理の自動化

ジョブは、テーブルをキューとして使用してSQL Server 2008データベースにキューイングされます。

キューから要素を取り除き、処理コードを実行する単純な「エンジン」が必要です。処理コードはC#/ .netになります。

私の主な関心事は、シンプルさ、テスト容易性、簡単な配備と信頼性です。

BizTalkやWindowsサービスのような技術に関する推奨事項をお探しですか?

+0

どういう意味ですか?すでにSQLとC#を使用すると言っています。あなたはこのコードを書く方法を尋ねていますか?まだ何か試したことがありますか? – spinon

+0

申し訳ありません。私が探しているのは、「エンジン」の部分の技術に関するアイデアです。私はすべての新技術について最新ではない。私は、コンソールアプリよりも「良い」ことが必要だと感じています。なぜなら、サーバから始まり、常に稼働し続ける必要があるからです。 – squareeyes

答えて

1

ここにいくつかのオプションがありますが、Writing a windows serviceは私が選ぶものです。リンクを確認してください。それは基本的な例を示し、あなたが始めるのを助けることができます。

別のオプションとして、SQL Serverエージェントをスケジューラとして使用して、必要に応じてC#実行可能ファイルを起動する方法があります。しかし、これは大きな選択肢ではありません。

0

私たちはどのような仕事をしていますか?ジョブ自体がデータベース作業で構成されている場合は、internal ActivationをSQL Serverに活用することをお勧めします。内部起動はC#/ .Netコードも起動できます。例については、Asynchronous procedure executionを参照してください。アクティベーションの使用は最も信頼性の高い方法です。スケジュールされたジョブは、ミラー化およびクラスタリングのフェイルオーバーを乗り越えることができます。実際には、スケジュールされたジョブは、新しいホスト上のデータベースバックアップからサーバーがクラッシュし、サーバーを再構築した後でもアクティブになり、実行されるため、信頼性が高くなります。しかし、ジョブが「外部」作業を行う必要がある場合、これは使用すべきではありません。 Webサービスに接続します。そのようなサービスでは、External Activatorを使用し、SQL Serverのアクティベーションメカニズムに固有の信頼性と自己バランスの尺度を活用できますが、最終的には依然としてWindowsサービスとService Brokerキューです。

組み込みのSQLキューのオーバーヘッドが高いとわかった場合は、Using tables as Queuesに進み、基本を固執することをお勧めします。キュー表にファンキーなピークやスキャンを追加しないでください。また、システムをデッドロックに陥らせることもあります。これは、表をキューとして使用する際の一般的な問題です。

関連する問題