Open yappo opened 10 years ago
現状の
if (-f $serial_number_file) { my $polled_log_file = '../data_files/songs/polled.log';
open my $frh, '<', $serial_number_file;
flock $frh, 1;
open my $fwh, '>>', $polled_log_file;
flock $fwh, 2;
seek $fwh, 0, 2;
print $fwh sprintf("%s\t%s\n", encode_utf8($title), encode_utf8($initial_group));
rename $serial_number_file, "${serial_number_file}_USED";
$status = 200;
}
ファイルハンドルが明示的に閉じられてないので見ててこわい。 そもそも rename が成功してるか成功してないかで、投票の処理を実行すれば良いかどうかがわかるので 先に rename してからログに書けば良い。
append mode は基本的には複数の write の内容は混ざらないので lock はなくていい ref. http://d.hatena.ne.jp/kazuhooku/20130930/1380543246
無限ループして lock 解除待つのまじやばい KENT 先生は優しく lock 処理実装してる
これ、 lock 中のプロセスが unlink 前に OOM Killer とかで死んだらどうしちゃうの。。。
ロック処理してる理由としては、投票数を $inital_group.ltsv の中に書き込みたいというのが多いと思うけど、楽曲が多いイニシャルグループだとロック競合が起こりまくって詰みます。 この場合は曲ごとに投票数をカウントしていくと競合が減って安全になるんですが
なるんですが
そもそもリアルタイム集計はしなくてもいいので、何時何分にどの ip address が、どのシリアルナンバーで、なにに投票した。っていうログファイルを append しまくって、集計が必要な時に集計すればよさそう。 最低でも100万シリアルナンバーなので、100万って知ってます?ビッグデータの b の字にすらならない超少数なんですよ!DQ10のMP無消費19%腕とか変えちゃうんですよ!
だっせんしたけど
なので、ログに書けばファイルを長時間ロックする必要はなくなるのであとは、アトミックにシリアルナンバーを消化すれば良くなった。 そこで rename(2) ですよ