我正在研究文档管理系统。一个示例工作流程是这样的：
由于我输入的音量会有所不同（但通常会很高），我对可扩展性非常感到欣慰。
例如，假设系统已下载电子邮件附件。如果附件是PDF文档，系统需要将PDF拆分为单独的页面，然后将每个页面转换为多个大小的缩略图等。我计划进行cron作业检查（例如，每分钟）以查看是否存在PDF需要处理的文件。使用标记系统（例如“PDF文档准备处理”），我可以检查数据库中标记为要处理的所有PDF文档。完成PDF处理后，可以更新标志以说“PDF Processing Done。”
但是，由于每个PDF文档的处理非常耗时，我担心在执行下一个cron作业时，该cron作业还将尝试处理前一个cron作业仍在处理的PDF。
可能的解决方案是立即使用“当前正在处理的PDF文档”标记PDF文档。这样，当执行下一个cron作业时，它将排除已经处理的作业。
因此，工作流程中的每个步骤可能都有3个标志：
QA相同：
这是一个好方法吗？有更好的方法吗？我会将这些标志作为数据库中“PDF文档”表的单个列吗？或者标志应该是它自己的表（例如，特别是如果文档可以设置多个标志）。
我想征求关于如何实施这样一个系统的建议。
答案 0 :(得分：2)
要解决您对同一文档的并发处理问题，可以使用许多调度程序包来帮助您管理此方面。 http://www.quartz-scheduler.org/是我用过的非常成功的。
为解决您的问题，我会收到3个状态，已收到，已排队，已处理（与您的建议类似）。
我有一个计划的定期作业，它会轮询数据库，查找收到的pdf，并为每个作业排队一个要处理的作业，并将pdf标记为已排队。如果你确保在同一个交易中发生这种情况，并利用乐观锁定，则不会有其他工作可能出现的风险并按原样重新阅读。
Quartz使用一个带有may配置选项的线程池，非常适合延迟的资源密集型处理（我在服务器设置中使用它进行图像缩略）。
要退后一步，java世界中有一些很棒的工作流程包可以处理你想要做的大部分工作，包括延迟的pdf处理。看一下jbpm或drools flow，这两个很好的，如果很复杂的包。
更新： Drools Flow已合并到JBPM中。对于这个特殊的问题，可能有点“用火箭筒杀死一只蚊子”的情况，但这是一个很棒的工作流程。
答案 1 :(得分：0)
解决方案的类型取决于您用于实现此系统的技术是通过与电子邮件软件相同的软件/语言完成的前/后处理？此外，他们在单独的过程中运行。
如果你有分布式组件，你可能比调查像RabbitMQ这样的AMQP解决方案更糟糕，因为这会将每个作业放入队列，并确保只有一个消费者接受每个作业。 （我们将每个缩略图作业建模为单独的任务）。
但是，如果整个系统都是用一种语言实现的，那么在一个过程中就可以使用一些更简单的系统：