23

既存のプロセスは、ユーザー入力に応じて、テーブル内の予約レコードのステータス フィールドを変更します。

特定のステータスのレコードに対して非同期で実行する、別のプロセスを作成する必要があります。テーブル レコードを読み取り、いくつかの操作 (サード パーティの Web サービスへの呼び出しを含む) を実行し、レコードのステータス フィールドを更新して、処理が完了したことを示します (または、エラー カウントでエラーが発生したことを示します)。

この操作は、キューに非常に似ています。この状況で、SQL テーブルではなく MSMQ を使用する利点とトレードオフは何ですか? また、どちらか一方を選択する必要があるのはなぜですか?

テーブル内のレコードを追加および更新しているのは、当社のソフトウェアです。

これは、非同期処理を実行する新しい作業 (Windows サービス) です。これは「常に稼働」している必要があります。

4

11 に答える 11

14

ここにある Fog Creek フォーラムで議論されたいくつかの理由があります。

主な利点は、コンピュータ間に断続的な接続がある場合でも MSMQ を使用できることです (ローカル マシンでストア アンド フォワード メカニズムを使用)。アプリケーションに関する限り、MSMQ はメッセージを後で配信する可能性がありますが、MSMQ にメッセージを配信しました。

データベースに接続できる場合にのみ、テーブルにレコードを挿入できます。

ワークフロー アプローチが必要な場合は、テーブル アプローチが適しています。プロセスはさまざまなステージを通過し、これらのステージは DB に永続化する必要があります。

于 2008-12-19T04:07:32.713 に答える
6

予約レコードが作成される頻度が低い場合は、2 番目のプロセスでテーブルを定期的にチェックして新しい予約を確認します。

既に MSMQ を使用していない限り、MSMQ を導入すると、サポートするプラットフォーム コンポーネントが追加されるだけです。

データベースの負荷が高い場合、または予約テーブルの同じ領域に対する 2 つのプロセスの読み取りと書き込みで多くのロック競合が発生する場合は、MSMQ の導入を検討してください。

于 2008-12-21T20:14:42.863 に答える
5

前のディスカッションでのle dorfierからのこの回答も気に入っています。

最初にテーブルを使用してから、理由がある場合 (および場合) に本格的な msg キューにリファクタリングします。これは、設計が合理的であれば些細なことです。

皆さん、すべての回答に感謝します。最も役に立ちます。

于 2008-12-21T19:57:28.470 に答える
4

MSMQ を使用すると、キューの場所を db サーバーではなく別のマシンに変更することで、作業を別のサーバーに簡単にオフロードすることもできます。

ところで、SQL Server 2005 の時点で、DB に組み込みのキューがあります。これは、SQL サーバー サービス ブローカーと呼ばれます。参照: http://msdn.microsoft.com/en-us/library/ms345108.aspx

于 2008-12-19T05:30:56.007 に答える
2

MSMQの専門知識がある場合は、それが適切なオプションです。データベースは知っているがMSMQは知らない場合は、別のテクノロジの専門家になりたいかどうかを自問してください。アプリケーションが重要なものであるかどうか。問題が発生したときにデバッグしたいものです。

于 2008-12-19T06:10:49.017 に答える
2

前の説明も参照してください。

于 2008-12-19T04:30:51.090 に答える
1

私は最近これを自分で調査しているので、私の発見に言及したかった. アプリケーションと比較したデータベースの場所は、どちらのオプションが高速かを決定する大きな要因です。

100 個のデータベース エントリを挿入するのにかかった時間を挿入するテストと、まったく同じデータをローカルの MSMQ メッセージに記録するテストを行いました。次に、このテストを数回実行した結果の平均を取りました。

私が見つけたのは、データベースがローカル ネットワーク上にある場合、行の挿入は MSMQ へのログ記録よりも最大 4 倍高速であるということです。

データベースが適切なインターネット接続を介してアクセスされている場合、データベースへの行の挿入は、MSMQ へのログ記録よりも最大 6 倍遅くなりました。

そう：

ローカル データベース - DB の方が高速ですが、それ以外の場合は MSMQ の方が高速です。

于 2013-10-03T10:57:21.830 に答える
0

私はおそらくMSMQ、またはActiveMQを自分で使用します。WCFを調べるか、.netコードを呼び出して処理を実行するトリガーを持つMS-SQL 2005+を使用している場合は、（MSテクノロジを使用してWindowsを使用しているMSMQを検討していると想定して）お勧めします。

于 2008-12-19T05:56:52.353 に答える
0

Service Broker は SQL 2005 で導入されました。プロセスが比較的単純であるため、メッセージを非常に迅速に処理できるように設計されています (そのルーツはトリガーにあると思います)。スケーラビリティが心配な場合は、SQL 2008 で独立した処理実行可能ファイルをリリースして、処理を SQL Server から分離しました (標準の Service Broker では、すべてが SQL Server インスタンスによって制御されます)。

MSMQ で Service Broker を使用することを検討することは間違いありませんが、これは SQL 開発/DBA リソースとその知識に依存します。

于 2008-12-19T19:23:43.187 に答える
0

生の MSMQ 呼び出しを行う代わりに、サービスをキュー COM+ コンポーネントとして実装し、クライアント アプリケーションからキュー関数呼び出しを行う方が簡単な場合があります。最終的に、非同期サービスは引き続き MSMQ をバックグラウンドで使用しますが、コードはより明確で使いやすくなります。

于 2008-12-19T04:24:58.980 に答える