Message Broker - 作业之间的依赖关系

Question

我正在尝试找到一个好的队列服务器/消息代理，它可以使我能够将作业推送到队列，而且还可以：

1. 建立作业之间的依赖关系（例如，仅在作业 A 完成后运行作业 B）
2. 如果订阅者执行失败，则允许重新运行任务（不将其从订阅者推回队列）
3. 持久性（在服务器重新启动等情况下）
4. 扩展（在服务器负载的情况下能够添加更多节点）
5. 优势：AWS 中的托管解决方案

我知道很多名字，比如 RabbitMQ、ActiveMQ、Kafka，但我想听到现实生活中的经验，而不仅仅是我已经读过的文章。

Answer 1

我也有同样的要求，我评估了 RabbitMQ 和 Apache Kafka 等不同的队列服务，但所有这些服务都需要我们维护自己的服务器并进行管理。这样做的问题是，维护我们自己的服务器成本很高，而且我们需要自己在可扩展性上进行管理（除非我们使用提供可扩展性的服务器）。

然后我切换到AWS SQS和AWS Lambda ，这非常适合我的要求。主要优点是，它完全无服务器，AWS将处理它的可扩展性。我们需要跟踪每项服务的限制，只有当我们扩展到非常大的级别时，这些限制才会受到影响。

现在，让我们看看该解决方案如何满足您的要求。

1. 建立作业之间的依赖关系（例如，仅在作业 A 完成后运行作业 B）

当 SQS 收到消息时，您可以调用 Lambda 函数（作业 A）并让该函数调用（作业 B）以确保维持顺序。在没有 Lambda 的情况下也可以使用类似的方法，您可以在每个作业完成后按照您想要的顺序发送消息。使用 AWS SQS 和 Lambda 的优点在于，SQS 提供了调用 lambda 的功能（该功能于 2018 年 6 月推出），我们不需要每次都轮询队列。

2. 如果订阅者执行失败，则允许重新运行任务（不将其从订阅者推回队列）

如果订阅者失败，您可以将消息发送到死信队列 (DLQ)，这是另一个 SQS 队列，用于存储接收者失败的消息。（请参阅此链接）。这样，您可以使用与 1 中提到的类似的方法，您可以让 DLQ 中的消息单独处理。

3. 持久性（在服务器重新启动等情况下）

SQS 会在给定的时间内保留您的消息。您可以指定要将消息存储在队列中的时间段。如果您想要硬持久性（在一定时间后不会过期），请考虑将其存储在数据库或其他存储机制（如 S3）中。

4. 扩展（在服务器负载的情况下能够添加更多节点）

默认情况下，AWS 提供高可扩展性，其中为每项服务设置了一定的限制。充分意识到局限性，只有当我们规模非常大时，它才会超越。（始终可以通过联系 AWS 支持团队来增加此值）

5. 优势：AWS 中的托管解决方案

如上所述，这些 AWS 服务由 AWS 本身管理。因此，只要您保持在限制范围内，就没有什么可担心的。

您在问题中提到的所有解决方案都很好，但其有用性取决于用例场景。根据提到的要求，AWS SQS将是这种场景的理想选择。