我们在应用程序中使用Quartz调度程序扫描特定文件夹中的任何新文件，如果有新文件，则启动应用程序中的相关工作流程以处理它。为此，我们创建了自定义侦听器对象，该对象与作业和触发器关联，该触发器每5分钟轮询一次文件位置。
要求是仅处理到达该文件夹位置的新文件，同时忽略已处理的文件。此外，我们不希望文件夹位置因大量文件而大幅增长（否则会降低文件夹扫描速度） - 所以在工作流程结束时我们实际上会删除源文件。
为了实现它，我们决定在作业元数据中维护已处理文件的列表。因此，在每次轮询时，我们从作业元数据中获取已处理文件的列表，将其与当前文件列表进行比较，如果文件尚未处理，则启动相关的流程。
上述方法的问题在于多年来（并且取决于每天接收的文件数量，可能是每天100K），作业元数据（持续处理的文件列表）变得非常大，它开始向我们提出数据截断错误（在石英表中持久化作业元数据）和缓慢的问题。
为解决此问题，我们决定使用文件夹的当前快照刷新作业元数据中已处理文件的列表。这样，由于我们在每个工作流结束时从文件夹位置删除已处理文件，因此处理文件列表仍然有限。但是，如果重复文件第二天到达，我们就会开始处理重复文件的问题。
实施此要求的最佳方法是什么，并确保我们不处理以相同名称到达的重复文件？我们是否应该考虑在外部数据库中持久处理文件列表而不是作业元数据的方法？我正在寻找实施此解决方案的推荐方法。谢谢！
答案 0 :(得分：2)
我们最近与我们的调度程序有类似的请求。如果您使用的是Linux，为何不使用inotify等解决方案？其他系统可能有其他方法来监视文件系统事件。
我们的解决方案是在每个创建事件中触发一些文件处理，然后每隔x天删除旧文件（类似于Walen DB建议）。在这种情况下，列表不会过度膨胀，并且可以在自己的特定情况下处理重复文件。
（抱歉，我无权发表评论。）