2

SAP からの何万ものレコードのフィードを処理する WCF サービスがあります。サービス コールは、XElement をメイン パラメータとして取り、XML を処理してデータベース内のレコードを更新します。現在の目的は、WCF サービスを非同期的に呼び出すことと、サービス呼び出しによって、処理された各レコードのステータスを含む同じドキュメントを呼び出し元に送り返すことです。

また、データの処理をマルチスレッド化する方法も検討していますが、これでは何も買えないかもしれません。

これには時間がかかる可能性があるため、WCF サービスが停止したり、再起動したりした場合にどうなるかが心配です。処理したレコードと処理していないレコードを把握し、処理を完了できるようにする必要があります。残りの記録について。

私が思いついた最善の方法は、各ノードをステータスで更新し (呼び出し元に送り返すために、とにかくこれを行う必要があります)、このファイルをハード ドライブに保存することです。しかし、潜在的に 100,000 倍のサイズのファイルを保存することは、実際には実行可能とは思えません。

これらの記録を処理しながら追跡するために、他にどのような戦略を使用できますか?

ティア！
ジェームズ

4

4 に答える 4

3

MSMQ を使用することは、あなたが概説したほとんどのニーズを満たす優れた方法だと思います。ノードをメッセージに分割し、それらをトランザクション キューに入力した場合。

  • データの処理のスケーリングは、1 つの能力を最大限に引き出したキューでより多くのマシンを処理することにより、より簡単になります。
  • WCF が「停止、再起動など」しても、何も失うことはありません。
  • このシナリオで発生する実際の問題は、サービスが処理中の場所をクライアントに把握させることです。キュー メッセージは一方向のみです。おそらく、キューの処理ステータスを評価する別のサービス コールが必要になるでしょう。

MSMQ WCF ハウツーへのリンク:

http://msdn.microsoft.com/en-us/library/ms789048.aspx

http://code.msdn.microsoft.com/msmqpluswcf

于 2010-12-10T18:00:27.957 に答える
1

おそらく、(XML からの) レコードを最初にデータベースに、おそらく特別な「処理するレコード」テーブルに入れることができます。各行には、特定のリクエストと関連付けるための何らかの方法でタグ付けすることもできます。データベースからの行を処理します。それぞれを処理するときに、ステータス フィールドを更新します (XmlElement で更新したノード ステータスに対応します)。終了したら、戻って XML を更新するか (その間にクラッシュしていない場合)、または新しい XML を生成することができます (変換 XML->database-> を往復できない場合は問題になる可能性があります)。 XML。

サービスが停止した場合、データベースを調べて未処理のレコードを見つけ、それらの処理を終了するのは比較的簡単です。

または、XML ファイルを一度ディスクに書き込み、「ステータス」フィールド (および XML ファイル内の対応するレコードを再度検索できるようにするための 1 つ以上のキー) のみを保持するテーブルをデータベースに保持し、レコードを処理することができます。データベースの「ステータス」テーブルを更新します。終了したら、「ステータス」テーブルからステータスを読み取って、XML ファイルのステータス フィールドを一気に更新します。

繰り返しになりますが、サービスが停止した場合、「ステータス」テーブルを調べて、どの行が処理され、どの行が処理されていないかを確認するのは簡単です。

幸運を！

于 2010-12-10T17:58:25.873 に答える
1

If your source and destination databases are SQL Server, then you should forget about middle-men and go straight to the built-in queuing support in the database: Service Broker. You get a number of advantages over MSMQ:

  • High Availability. Service Broker is built into the database, so the database high availability and disaster recoverability solution you already have implemented will automatically pick up your messaging solution too. Your cluster or database mirroring solution will work out-of-the-box and the messaging will fail-over transparently with the database failover.
  • recovery consistency. Having you messages and you data in the same recovery unit (the 'database') allows for simple backup-restore. With messages stored in MSMQ and data stored in database is not possible to have a consistent backup unless you freeze processing.
  • routing. SSB allows for queues to move to new physical locations w/o interrupting the message stream. See Service Broker Routing.
  • increased capacity. MSMQ have a very small size limit (4GB per queue) which can be quickly overrun in production, with disastrous results. SSB limit is 2GB per message and the queue size limits are the database size limits.
  • significantly higher throughput due local transactions instead of distributed transaction. With MSMQ you must enroll the database and the MSMQ into a distributed transaction, bot at the end where you enqueue and at the end where you dequeue. This dramatically reduces the throughput in MSMQ case.

There are other advantages too:

The one thing you loose is the WCF service model programming. WCF makes it indeed extremely easy to write demo apps and you'll loose that.

于 2010-12-10T18:38:49.517 に答える
0

Microsoft Message Queuingなどのメッセージング サーバーを検討したことがありますか。

于 2010-12-10T18:00:00.093 に答える