1 日あたりの IP が高くないか、同時実行数がそれほど多くないアプリケーションの場合は、通常、これらを考慮する必要はありません。通常のファイル操作方法では全く問題ありません。しかし、同時実行性が高い場合、ファイルの読み取りと書き込みを行うときに、ファイルへのアクセスがそれに応じて独占されないと、複数のプロセスが次のファイルに対して動作する可能性が高くなります。
例:オンラインチャットルーム(チャット内容がファイルに書き込まれるものとします)では、ユーザーAとユーザーBの両方が同時にデータ保存ファイルを操作する必要があります。まず、Aがファイルを開き、次に、その中のデータを更新しますが、ここでは、B たまたま同じファイルが開かれ、その中のデータが更新されようとしていたところです。 A が書き込んだファイルを保存すると、実際には B がそのファイルを開いていることになります。しかし、B がファイルを保存し直すと、すでにデータ損失が発生しています。ユーザー B は、変更したときに開いたファイルを知らないため、ユーザー A もファイルを変更したため、最終的にユーザー B が変更を保存するときに、ユーザーA の更新は失われます。このような問題に対する一般的な解決策は、あるプロセスがファイルを操作するときに、まず他のプロセスをロックすることです。つまり、このプロセスだけがそのファイルを読み取る権利を持ち、他のプロセスがそのファイルを読み取ることはできなくなります。まったく読み取ることはできませんが、この時点でプロセスがファイルを更新しようとすると、以前にファイルをロックしていたプロセスがファイルの更新操作を完了すると、その操作は拒否されます。 、ファイルは変更可能な状態に復元されます。次に、同様に、プロセスがファイルを操作するときにファイルがロックされていない場合は、ファイルを安全にロックして単独で楽しむことができます。
一般的な解決策は次のとおりです:
オプション 2: flock 関数を使用せず、一時ファイルを使用して読み取りと書き込みの競合の問題を解決します。一般原則は次のとおりです:
(1) 更新する必要があるファイルのコピーを一時ファイル ディレクトリに置き、ファイルの最終変更時刻を変数に保存し、この一時ファイルにランダムな困難なファイルを与えます。 -リピートするファイル名。 (2) この一時ファイルを更新した後、元のファイルの最終更新時刻が以前に保存した時刻と一致しているかどうかを確認します。
(3) 最終変更時刻が同じ場合、変更された一時ファイルの名前を元のファイルに変更します。ファイルのステータスが同期して更新されるようにするには、ファイルのステータスをクリアする必要があります。
(4) ただし、最終変更時刻が以前に保存された時刻と一致する場合は、この期間中に元のファイルが変更されたことを意味し、この時点で一時ファイルを削除する必要があり、それを示す false を返します。現時点では、ファイルには他の変更が加えられています。プロセスは実行中です。
実装コードは次のとおりです:
オプション 3: 同時実行の可能性を減らすために、操作されたファイルをランダムに読み書きします。
このソリューションは、ユーザーのアクセスログを記録するときによく使用されるようです。以前は、ランダムなスペースを定義する必要がありました。スペースが大きいほど、同時実行の可能性は低くなります。ランダムな読み取りおよび書き込みスペースが [1 ~ 500] であるとすると、ログ ファイルの分布は log1 から log500 の範囲になります。ユーザーがアクセスするたびに、log1 ~ log500 までの任意のファイルにデータがランダムに書き込まれます。同時に、2 つのプロセスがログを記録しています。プロセス A は更新された log32 ファイルである可能性がありますが、プロセス B はどうなるでしょうか。このときの更新は log399 になる可能性があります。プロセス B にも log32 を実行させたい場合、確率は基本的に 1/500 であり、ほぼゼロに等しいことを知っておく必要があります。アクセスログを分析する必要がある場合、ここでは、最初にこれらのログをマージしてから分析するだけです。このソリューションを使用してログを記録する利点の 1 つは、プロセス操作がキューに入れられる可能性が比較的小さく、プロセスが各操作を非常に迅速に完了できることです。
オプション 4: 操作するすべてのプロセスをキューに入れます。 次に、ファイル操作を完了するための専用サービスを配置します。キュー内の除外された各プロセスは最初の特定の操作に相当するため、ここに多数のファイル操作プロセスがある場合、初めてサービスはキューから特定の操作アイテムを取得するだけで済みます。列の最後尾に並んでください。列に並ぶ意思がある限り、列の長さは関係ありません。
前述のオプションには、それぞれ独自の利点があります。これは、大きく 2 つのカテゴリに分類できます:
(1) オプション 1、2、4 などのキューイングが必要 (影響が遅い)
(2) キューイングは必要ありません。 (ファーストインパクト) オプション 3
キャッシュ システムを設計する場合、通常、オプション 3 は使用しません。案3は解析プログラムと書き込みプログラムが同期していないため、書き込みの際に解析の難易度は全く考慮されず、書き込みがよければ問題ありません。想像してみてください。キャッシュの更新時にランダムなファイルの読み書きも併用すると、キャッシュの読み込み時に多くの処理が追加されそうです。ただし、オプション 1 と 2 はまったく異なりますが、書き込み時間はかかりますが (ロックの取得に失敗した場合は繰り返し取得されます)、ファイルの読み取りは非常に便利です。キャッシュを追加する目的は、データ読み取りのボトルネックを軽減し、それによってシステムのパフォーマンスを向上させることです。
上記は個人的な経験といくつかの情報の要約です。間違っている点や言及されていない点がある場合は、同僚が私を修正することを歓迎します。