Architecture 审查任务队列系统

我正在实现一个审查系统，用户上传需要审查的数据项，审查人员审查并提供评论。每个数据项需要由3名审核人审核

项目应或多或少按顺序进行处理-理想情况下，项目A将添加到系统中，由审核人1、2和3审核并返回给用户。然后项目B被添加到系统中，评审员2、5、1对其进行评审，依此类推。当然，由于审阅者可以同时工作，并且有3个以上的审阅者，因此系统应该支持多个项目同时审阅（当然是由不同的审阅者）

我不确定如何实现数据项存储库。这些要求是：

• 项目由多个编写器添加
• 每个项目由3个不同的读者阅读
• 当读者阅读一个项目时，它应该阅读读者没有首先看到的第一个项目

我可以使用SQL数据库实现所有这些，但它的扩展性不太好

---

是否有现成的排队系统支持这样的东西（基本上，弹出不符合标准的第一个项目）？或者通过某种方式将其添加到现有的排队系统中？

鉴于SQL数据库是许多企业级系统的基础，我认为“它不会很好地扩展”的说法没有任何依据。的确，大型企业系统受益于专用排队系统，但这些系统正在处理零售银行一天内要处理的所有交易。我怀疑你是否有那么多的项目需要审核，那么多的并发审核人，以至于这一要求会给标准的SQL数据库带来压力——6000名审核人每小时处理60个项目只会给出几百个测试程序集。当然，我在猜测您的需求规模，因此了解它们是什么可能会很有趣

然而，我可以看到将其作为一组队列实现的概念上的优点，原则上的要求是能够“从这个队列中为我提供我尚未检查过的下一个项目”

---

JMS选择器允许您根据标题字段内容选择记录，因此向消息中添加Reviewer1和Reviewer2标题字段应允许高效选择下一个可用项。因此，我猜想任何JMS complient队列系统都足够了

这是一个非常不具体的问题，很难回答。你是想让我们告诉你在Django该怎么做？因为这基本上意味着我们必须教你如何使用Django。不，不，我要澄清。SQL数据库的队列管理器非常差。这就是企业级系统使用企业级队列管理系统的原因。关于JMS系统，这是一个好主意。对于这个问题，我将扩展我对SQL DB的想法。现在这是一个预算问题。如果我购买一个企业级Oracle许可证并将其安装在足够漂亮的硬件上，它将能够处理我预测的队列负载。我不会这样做，我会在一个相对便宜的虚拟服务器上使用一个免费的PostgreSQL数据库。使用合适的排队系统要比在数据库性能达到合适的排队系统性能之前对其进行升级便宜得多。