我正在为我开发的一些服务构建的日志文件系统进行演变。我以前一直在打开文件，附加数据，然后写入检查以查看日志文件是否已经增长超过预定的大小，如果这样，则开始新的日志。
所以说日志大小是100mb，在我删除的那个大小，并开始一个新文件，但我放弃了历史，功能，但不是最好的模型。
我想要做的是一个FIFO模型，它会切断顶部并添加到最后，同时保持它始终不超过100mb，并且至少可以追溯到那个代表。
数据在容易出故障的工业环境中是高速的，因此将其全部保留在内存中并间隔写入整个文件已被证明是不可靠的。 （SSD，足够快，合理地大多数当时，旋转器经常失败而不能容忍）
同样，记录的长度变化很大（格式化为XML节点，因此很容易将它们解析出来）
因此，到目前为止我唯一可行的模型是保留较小的切片（比如10mb）块，创建新的切片然后删除最早的10mb切片计数＆gt; = 10.
我更喜欢的是能够将文件保存在磁盘上并使用标记结束。
可以合理地了解如何最好地实现这一目标，或者没有合理的方式，分层多日志方法将是最佳选择？
答案 0 :(得分：3)
在单个文件中使旧日志条目过期的最大问题是您必须重写文件的内容才能使旧条目过期。这对于小文件（最大几MB）来说并不算太糟糕，但是一旦你达到重写需要很长时间的程度就会出现问题。
退役日志的一种常见方法是重命名现有日志文件和/或启动新文件。许多程序以这种方式执行，使用过时的日志文件名或使用顺序编号系统 - logfile，logfile.1，logfile.2等，其中较高编号的文件较旧。您可以向流程添加压缩，以进一步降低过期文件的存储要求等。
另一个选择是使用更像数据库的格式，或者像SQLite这样的彻头彻尾的数据库来存储您的日志条目。这当然的主要缺点是你的日志文件变得更难阅读，因为它们不仅仅是纯文本形式。编写转储到文本程序很简单，其输出可以通过管道传递给日志解析器......但即便如此，也可能需要更改消费者与日志文件的接口方式。
我怀疑，所述问题不太可能实际解决。一方面，您具有文件操作的局限性，另一方面，您的日志使用者很多且各种各样，因此对日志记录结构的更改将是一个涉及的过程。
关于我可以建议的所有内容是您尝试类似于此的日志老化过程：
注意重复或数据丢失。
答案 1 :(得分：1)
我不知道为什么你需要这个功能“砍掉顶部并添加到最后，同时保持不超过100mb”。
一般设计方法是归档。只需将超大文件重命名为另一个文件，或将其移动到其他位置，然后使用与新文件相同的文件名。
这很简单。