2

私は、POS からデータを収集し、それを中央データベースに挿入する既存のシステムを更新するように割り当てられました。現在機能しているものは FTP/SFTP 送信に基づいており、情報は 1 日 1 回、通常は夜間に送信されます。残念ながら、接続リンクが不安定なため (低品質の 2G/3G モデム)、一部のファイルが壊れているようです。そのように接続された数店舗だけではすべてがスムーズに機能していましたが、店舗が増えるにつれてエラーが頻繁に発生しました。さらに悪いことに、

私のマネージャーが提案したアイデアは、日中、継続的にデータを送信することです。データ パッケージが大幅に小さくなるため、転送と挿入がはるかに高速になり、中央サーバーには実際の (ほぼリアルタイムの) データが格納され、夜間はバックアップの作成やインデックスの再構築などの長時間実行されるデータベース アクティビティに使用できるようになります。

多くのWebサイトを調べた後、次のことがわかりました。

  • ASMX Web サービスの使用は廃止され、代わりに WCF を使用する必要があります
  • MSMQ またはシステム メッセージングを備えた WCF を使用すると、データの配信、一貫性、オフラインになるノードなどの確認についてあまり気にする必要がない場合に、データを安全に送信できます。
  • http://blogs.msdn.com/b/motleyqueue/archive/2007/09/22/system-messaging-versus-wcf-queuing.aspxによると、WCFキューイングの方が優れています
  • RabbitMQ、ZeroMQ など、メッセージ キューを実装するための他のテクノロジもあります。

そして、それが私が混乱するところです。非常に多くのオプションがありますが、これらのテクノロジーの長所と短所はありますか? Windows Forms と SQL Server で .NET を使用していましたが、必要に応じて、より適したものに変更できます。サーバーの効率も少し心配です。いくつかの計算の後、サーバーは 1 秒あたり約 15 パッケージのデータを受信します (ピーク)。多いですか?本格的なサーバー インフラストラクチャを持たず、オンラインで何百人もの訪問者を処理し、スムーズに動作する Web サイトが多数あることは知っていますが、Web サイトは主にクライアントにデータをアップロードし、ここではクライアントからデータをダウンロードします。

また、やや似た SO の質問も見つかりまし た。DDS が言及されている分散システムのデータ収集と監視を構築するためのミドルウェアです。メインサーバーが 1KB/s の転送で詰まらないように、POS への低品質のリンクに対処するミドルウェアサーバーを導入することについてどう思いますか?

どうぞよろしくお願いいたします。前もって感謝します!

4

2 に答える 2

0

私が理解していることから、基本的に2つの問題があります。

  1. 通話データの損失/破損の可能性
  2. データベース書き込みパフォーマンス

通話データの損失/破損の可能性は、クライアントからサービスへのデータ転送における信頼性の欠如によって引き起こされています。

また、データベースの競合/パフォーマンスの問題を引き起こしている原因は明確ではなく、大容量への漠然とした言及を超えているため、この回答は最初の問題の解決に重点を置いています。

現在のセットアップにおける信頼性の問題に対処する方法として、信頼性の高い非同期通信トランスポートの必要性を正しく認識しました。

これを実現するために MSMQ を検討することは、有効な最初のステップです。MSMQ は、すぐに使えるストア アンド フォワードメッセージング セマンティックを介して信頼性の高い通信を提供し、構成の方法はほとんど必要ありません。

残念ながら、MSMQ はニーズには適していますが、次の 2 つの点に依存しています。

  1. 信頼できるネットワーク プロトコル、および
  2. 送信側と受信側の両方のマシンで実行されるクライアント サービス。

上記の説明から、1 が存在するとは思えません (インターネットは信頼できるネットワークではありません)。また、2 に苦労する可能性があります。下...)

ネットワークの信頼性の問題に対する可能な解決策として、WCF または RESTful エンドポイント ( NancyまたはWebApiを使用) を使用して、HTTP 経由で公開されるサービス操作を公開し、クライアント マシンからの着信呼び出しを受け入れることができます。これらのテクノロジはまったく異なるため、早い段階で正しい選択を行っていることを確認する必要があります。

WCF は、SOAP 1.2 仕様のWS-ReliableMessagingをすぐにサポートします。これにより、http を介した信頼性の高い Web サービス呼び出しが可能になります。

REST は .Net の WCF よりもはるかに単純で、非常に軽量で使いやすいです。ただし、信頼性の高い配信を行うには、(クライアントがデータを送信できるようにするための POST に加えて) ある種の GET 操作を公開して、データがコミットされたことを確認するために (妥当な時間枠内で) 呼び出される必要があります。GET「確認応答」の結果が否定的だった場合、クライアントは何らかの再試行セマンティックを実装する必要があります。

WCF ルートでは 1 つではなく 2 つの操作が必要ですが、私は REST アプローチを好みます。私は両方をたくさん行ってきましたが、REST サービスの方が使いやすいと感じています。

(*) これは、MSMQ が最終的なソリューションで機能しないということではなく、伝送の信頼性の問題に対処するために使用されないということです。ただし、データベース書き込みの競合という別の問題に対処するために引き続き使用できます。着信リクエストがサーバーに到着したときにキューに入れる場合、これらは「オフライン」プロセスによって処理され、必要なデータベース操作を信頼できる方法で実行できます。これは、MSMQ トランザクション キューを使用して行うことができます。

コメントへの対応:

99% のメッセージはショップからメイン サーバーに渡されますが、何らかの変更 (価格の修正、割引など) が必要な場合は、そのデータをショップに送信する必要があります。

この種のものは変化します。双方向の要件があることを最初から理解していて、msmq 通信の確立に成功した方法を見て、MSMQ の非常に優れたラッパーである NServiceBus を勧めていたでしょう。私がこれを行った理由は、NServiceBus によって非常にうまくサポートされている、一方向とパブリッシュ/サブスクライブの両方の要件があるように見えるからです。

于 2015-05-11T15:17:11.973 に答える