1

これは非常に一般的なシナリオです。一部のプロセスが 30 分ごとにサーバーにファイルをドロップしたいとします。シンプルですね。まあ、これがうまくいかない方法はたくさん考えられます。

たとえば、ファイルの処理には 30 分前後かかる場合があるため、前のファイルの処理が完了する前に新しいファイルが到着する可能性があります。まだ処理中のファイルをソース システムで上書きしたくありません。

一方で、ファイルが大きいため、アップロードが完了するまでに数分かかります。部分ファイルの処理を開始したくありません。ファイルは FTP または sftp (私の好み) で転送されるだけなので、OS レベルのロックはオプションではありません。

最後に、ファイルの 1 つを (デバッグのために) 手動で検査したり、再処理したりする必要がある場合に備えて、ファイルをしばらく保持する必要があります。

私は、アップロード ファイルをシャッフルしたり、ファイル名を交換したり、日付スタンプを使用したり、「インジケーター」ファイルに触れて同期を支援したりするためのアドホックなアプローチを数多く見てきました。私がまだ見ていないのは、並行性、一貫性、および完全性に対処する、ファイルを処理するための包括的な「アルゴリズム」です。

そこで、ここで群衆の知恵を活用したいと思います。バッチ データ ファイルをジャグリングする本当に防弾の方法を見た人はいますか?

4

3 に答える 3

1

OSがサポートしている場合は、ファイルシステムフックを使用して、ファイルのオープン操作とクローズ操作をインターセプトします。ダズコのようなもの。他のオペレーティングシステムでは、ファイル操作について別の方法で通知される場合があります。たとえば、Novell Open Enterprise Serverでは、エポックを定義し、エポック中に変更されたファイルのリストを読み取ることができます。

Linuxでは、inotifyサブシステム、またはinotify-toolsパッケージのユーティリティを使用できることに気づきました。

于 2009-03-09T09:02:58.533 に答える
1

重要なのは、送信側で最初のジャグリングを行うことです。送信者が行う必要があるのは、次のとおりです。

  1. 一意のファイル名でファイルを保存します。
  2. ファイルが送信されるとすぐに、それを eg という名前のサブディレクトリに移動しcompletedます。

受信側プロセスが 1 つしかないと仮定すると、受信側が行う必要があるのは次のとおりです。

  1. completedディレクトリを定期的にスキャンしてファイルを探します。
  2. ファイルが に表示されたらすぐにcompleted、それを eg というサブディレクトリに移動し、processedそこから作業を開始します。
  3. 必要に応じて、終了したら削除します。

健全なファイルシステムでは、同じファイルシステム/ボリューム内でファイルの移動が発生する場合、ファイルの移動はアトミックです。したがって、競合状態はありません。

複数のレシーバー

ファイルが配信される間隔よりも処理に時間がかかる可能性がある場合は、複数の受信者プロセスがない限り、バックログが蓄積されます。では、複数のレシーバーのケースをどのように処理するのでしょうか?

シンプル: 各受信側プロセスは以前とまったく同じように動作します。processed 重要なのは、作業する前にファイルを移動しようとすることです。つまり、同じファイルシステムのファイルの移動がアトミックであるという事実は、複数の受信者が同じファイルを見completedて移動しようとしても、1 つだけが移動することを意味します。成功した。必要なことは、 の戻り値rename()、または移動を実行するために使用する OS 呼び出しを確認し、成功した場合にのみ処理を続行することだけです。移動が失敗した場合は、他の受信者が最初にそこに到達したので、戻ってcompletedディレクトリをもう一度スキャンしてください。

于 2009-03-07T20:15:50.790 に答える
0

ファイル転送は、システム統合の古典の1つです。エンタープライズ統合パターンの本を入手して、これらの質問に対する独自の回答を作成することをお勧めします。回答は、エンドポイントの実装とファイル転送に使用しているテクノロジーとプラットフォームによってある程度異なります。これは、実行可能なパターンの非常に包括的なコレクションであり、かなりよく書かれています。

于 2009-03-07T22:06:37.293 に答える