分布式队列适合构建可扩展的案例分配系统吗？

Question

这是我的目标基本功能。

1. 新用户注册其详细信息并上传一些文档。这会创建一个新案例。
2. 审核员每天早上登录并从积压的案件中选择一个待处理的案例。
3. 如果所有文件看起来都不错，审核员就会批准，否则会拒绝该案例。

我的看法

1. /register

   运行一个 POST 方法端点，该端点从分片 MySQL 数据库中捕获用户的详细信息，以及他们在 BLOB 存储中提交的任何文件（在 MySQL 中更新的引用）。
2. 成功注册会向分布式队列发出一个带有用户 ID 的事件，目前我正在考虑使用 Amazon SQS，但我想了解是否有任何开源替代方案可以防止我被供应商锁定。

3. /audit

   审核员将调用 POST 方法端点从队列 (SQS) 中获取一个条目，并更新此案例的状态，因此其他审核员最终不会得到相同的案例。如果他们能够获得这种情况下的锁，那就很好，否则再尝试队列中的下一个项目。

4. /register

   和

   /audit

   将是单独的服务，因此它们可以独立扩展和缩小。

我开始重新考虑是否要引入队列。我最好只查询数据库吗？像

SELECT Id FROM USER WHERE status = ‘Pending’ FOR UPDATE 

之类的东西

您将如何构建一个可以根据注册负载和审核负载进行动态扩展的系统？您将如何构建一个可以根据注册负载和审核负载进行动态扩展的系统？

Answer 1

我开始重新考虑是否要引入队列。我最好只查询数据库吗？类似 SELECT Id FROM USER WHERE status = ‘Pending’ FOR UPDATE

通常在自动管道中引入队列来去同步和解耦单个处理步骤，但这似乎不是您的情况。另外，在这个级别上，队列本身与普通表非常相似，它主要在其之上添加一个通知系统（锁定您已经在 SQL 中获得的），因此，如果您可以从程序中发送电子邮件或类似内容，在一些专用桌子的顶部应该就是您所需要的。

因此，我认为您可以使用代表 注册数据和批准状态 的表（或者更确切地说，一组相关表）（批准状态定义本身来自状态转换图或类似的指定 批准）生命周期）。

另一方面，我建议不要只在主 USER 表中完成所有操作：当然，如果您想要可扩展性，但我认为在任何情况下，为了实现此类实现的清晰度和可管理性，这都是可取的。

您将如何构建一个可以根据注册负载和审核负载进行动态扩展的系统？

说“动态扩展”有点不恰当，要么系统被设计为可扩展，要么不是：换句话说，我们可以“动态扩展”，例如服务器资源，而不是应用程序逻辑和代码。也就是说，我会使用上面解释的专用表格，它确实可以扩展。