3

これは、アップロードされた大量のデータを受信し、処理し、結果を返す Web アプリケーションを作成する方法に関する一般的な設計上の問題です。

要件は次のとおりです。

  • URL のリストを含む CSV ファイルをアップロードできる Web フォームを作成する
  • ユーザーが「送信」をクリックすると、サーバーはファイルを取得し、各 URL が有効かどうか、およびページのタイトル タグが何であるかを確認します。
  • 結果は、UR​​L を含むダウンロード可能な CSV ファイルと、結果の HTTP コードです。
  • 入力 CSV は非常に大きくなる可能性があるため (> 100000 行)、フェッチ プロセスに 5 ～ 30 分かかる場合があります。

これまでの私の解決策は、クライアント サイトに回転する JavaScript ループを配置することです。このループは、毎秒サーバーにクエリを実行して、ジョブの全体的な進行状況を判断します。これは私には不親切に思えます。これを最善の解決策として受け入れることをためらっています。

私は perl、テンプレート ツールキット、および jquery を使用していますが、任意の Web テクノロジを使用した任意のソリューションが受け入れられます。

編集: 可能な解決策の例は、この質問にあります:基本的な「ロングポーリング」を実装するにはどうすればよいですか?

4

3 に答える 3

3

これは AJAX で行うことができますが、COMET のような実装を使用すると、より優れたリアルタイムの結果が得られる場合があります。COMET の実装は、いくつかのタイムアウト制限を回避するように特別に設計されていると思いますが、私は何も使用していないため、直接的なガイドを提供することはできません。

いずれにせよ、サーバーに到達したら、別のプロセスに作業を渡すことをお勧めします。

私は、この性質のバッチ タスクに対してさまざまな解決策を試してきましたが、私が最も気に入っているのは、バッチ作業を別のプロセスに引き渡すことです。このようなシステムでは、アップロード ページは作業を別のプロセッサに渡し、ユーザーがプロセスを監視するよう指示してすぐに戻ります。

バッチ プロセッサは、次の 2 つの方法で実装できます。

  • 子を fork して IO から切り離し、バッチ処理を完了します。親が Web 要求を完了します。
  • アップロード コンテンツを処理キュー (例: ファイル システム上のファイル、データベース内のレコード) に保存し、Web サーバーに外部プロセッサ (カスタム デーモン、または *nix の「at」などの市販のスケジューラ) に通知させます。システム。

次に、プロセスを監視する複数の方法をユーザーに提供できます。

  • アップロード確認ページには、バッチ プロセスの同期ライブ モニターが含まれています (COMET または Flash 経由)。完了すると、確認ページでユーザーをダウンロードに誘導できます。
  • 上記と同様ですが、モニターはライブではなく、代わりに AJAX またはページ メタ更新による定期的なポーリングを使用します
  • 実行中のバッチ プロセスのステータスを表示するキュー モニター ページ。

バッチ プロセッサは、さまざまな方法でステータスを伝えることができます。

  • データベースのレコードを更新する
  • 処理ログを生成する
  • 名前付きパイプを使用する

コードを別のプロセスに渡すことには、多くの利点があります。

  • ユーザーが誤ってブラウザを停止した場合、プロセスは続行されます。
  • 外部プロセスを使用すると、モニターを取り外していつでも再接続できるように、バッチ ステータスを伝達する必要があります。例: プロセスが完了する前に、ユーザーが誤ってページから移動した場合。
  • Web トラフィックが少ない時間帯にバッチ処理を分散して実行する必要があると判断した場合は、バッチのスロットリングと延期を実装する方が簡単です。
  • Web タイムアウト (クライアント側またはサーバー側) について心配する必要はありません。
  • バッチ プロセスを中断しているかどうかを気にすることなく、Web サーバーを再起動できます。
于 2010-06-09T01:13:07.587 に答える
1

最も簡単なのは、バッチ処理またはジョブのストリーミングです。ページにあるデータテーブルのように扱う場合。テーブルに 100000 件を超えるレコードがある場合は、すべてのレコードを一度に要求します。私はこれをします：

  1. ファイルのダウンロード要求を送信します。

  2. 100 (任意の数) レコードを処理するリクエストを送信します。

    a. レコードを処理します。

    b. 一時 csv ファイルに保存します。

    c. プロセスの完了/未完了のステータスを返信します。

    d. ステータスが完了していない場合は、手順 2 を繰り返します。

于 2010-06-09T05:13:58.490 に答える
0

クライアントは信頼できないとおっしゃいましたので、(クライアント側で) X 個のレコードごとにファイルを事前解析し、レコードの各サブセットにチェックサムを追加してから、クライアントが一定数の接続をアップロードできるようにすることをお勧めします。これにより、進行状況をより正確に監視できます。

于 2017-08-07T05:08:05.723 に答える