2

基本的にデータベースのフロントエンドである、さまざまな古い学校のクライアント サーバー C# WinForm クライアント側アプリがあります。次に、クライアント アプリが注文を送信するのを待機し、注文を処理する C# サーバー側 Windows サービスがあります。

サーバー側サービスが実行する作業があるかどうかを確認する方法は、データベースをポーリングすることです。何年にもわたって、待機中の注文をポーリングするロジックは、無数のビジネス ルールのためにさらに複雑になりました。このため、ポーリング ストアド プロシージャ自体は、何もする必要がない場合でも、かなりの量の SQL Server リソースを使用します。これに加えて、注文が送信された瞬間に注文が処理されるという要件が追加され、データベースが絶えずポーリングされているため、パフォーマンスの問題が発生します。

セットアップは実際には今のところ問題なく動作していますが、負荷が屋根を通り抜けようとしているため、持ちこたえられないことは明らかです.

多数の異なるクライアント側アプリとサーバー側 Windows サービスの間で通信するための効果的な方法は何ですか?現在の方法よりも将来性がありますか?

データベース サーバーは SQL Server 2005 です。実際に最新の SQL Server にアップグレードするほどの力を手に入れることはできますが、その戦いには参加したくありません。

4

5 に答える 5

3

クライアントに通知する方法は多数あります。

  • NServiceBusのような既製のソリューションを使用して、サーバーからクライアントまたは他のサーバーに情報を公開できます。NServiceBusは、MSMQを使用して、非常に簡単で耐久性のある方法で1つのメッセージを複数のサブスクライバーに公開します。
  • MSMQまたは別のキューイング製品を使用して、クライアントに配信されるサーバーからのメッセージを公開できます。
  • WindowsサービスでWCFサービスをホストし、Duplexチャネルを使用して各クライアントからWCFサービスに接続できます。変更があるたびに、サービスは適切なクライアントまたはすべてのクライアントに通知します。これはコーディングがより複雑ですが、はるかに柔軟です。おそらく、データベースをまったくポーリングする必要がないほど十分な情報をクライアントに送り返すことができます。
  • サービスにUDPパケットをすべてのクライアントにブロードキャストさせて、プルする必要のある変更があることをクライアントに通知することができます。おそらく、クライアントがサーバーからデータをプルする必要があるかどうかを判断できるように、パケットに十分な情報を追加できます。これはサーバーとネットワークにとって非常に軽量ですが、すべてのクライアントが同じLANにあることを前提としています。
于 2012-06-14T18:25:19.547 に答える
1

最も簡単で、おそらく最も安価な答えは、より大きなサーバーを購入することです。

それがなければ、早期に失敗する可能性が高い開発作業を行うことになります。失敗とは、最終的に構築したものを削ってしまうという意味ではありません。むしろ、変更を開始すると、無数のビジネス ルールをデバッグしている間に注文が台無しになるということです。

率直に言って、プレッシャーの下でコミュニケーションの変更に取り組むことは考えていません。短期的に「屋根を通り抜ける」負荷についてのあなたの声明を推測します。

1 日目で 100% 機能しなければならないリスクがある場合 (注文の大幅な増加が予想される場合は正常です)、問題なく DB サーバーをアップサイズします。一体、最新のSQLサーバーをインストールすることさえしません。代わりに、より大きなマシンを購入し、まったく同じ OS と DB サーバー (およびパッチ レベル) をインストールして、データベースを移動します。

次に、アーキテクチャを調べて、何をなくす必要があり、何を回復できるかを判断します。

于 2012-06-14T18:49:02.393 に答える
1

おそらく、 SqlDependencyを利用して、データが実際に変更された場合にのみ通知を受け取ることができます。

于 2012-06-14T18:11:49.447 に答える
1

MSMQ、JMS、TIBCO などの任意のメッセージング ミドルウェアを使用して、クライアントとサービスの間で通信できます。

于 2012-06-14T18:21:55.290 に答える
1

全員が SQL Server に接続する場合は、Service Brokerのオプションもあります。これまでに推奨された他のメッセージング/キューイング ソリューションとは異なり、データベースに完全に含まれており (展開、管理、および構成する別の製品はありません)、バックアップ/リカバリおよび高可用性のニーズに対して単一のストーリーを提供します (個別のバックアップはありません)。メッセージ ストアの場合、個別の DR/HA は必要ありません。DB ソリューションが何であれ、メッセージング ソリューションでもあります)、統一されたプログラミング API (SQL) を使用します。

すべてが 1 つの SQL Server インスタンス内にある場合 (つまり、複数の SQL サービス インスタンス間でネットワークを介して通信する必要がない場合) であっても、Service Broker には、誰も対応できないエースがあります。アクティブ化を使用すると、処理するイベントがある場合にシステム自体が処理コードを起動する (「アクティブ化」する) ため、ポーリングの必要が完全になくなります。処理コードは、内部 (T-SQL プロシージャまたは SQLCLR .Net プロシージャ) または外部 (外部アクティベーターを参照) にすることができます。

于 2012-06-14T20:17:25.063 に答える