消息代理 - 作业之间的依赖关系

Question

我正在寻找一款优秀的队列服务器/消息代理，它可以让我在将任务推送到队列时具备以下功能：

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

我知道许多服务器名称，如 RabbitMQ、ActiveMQ 和 Kafka，但我想听听真实的使用经验，而不是已经阅读过的文章。

- Shlomi

---

所以你想通过消息代理来编排工作流程？在我看来，这里并不需要消息传递 - 已经有现成的解决方案，比如Apache Oozie（Hue在这里非常有用），可以管理和编排复杂的作业依赖关系。 - codejitsu

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月引入的功能），因此我们不需要每次轮询队列。

允许重新运行任务，如果订阅者无法执行它（而不将其推回队列）

如果订阅者失败，则可以将消息发送到Dead Letter Queue（DLQ），这是另一个SQS队列，用于存储接收方未能处理的消息（请参见this link）。通过这种方式，您可以使用与1中提到的类似方法，让DLQ中的消息单独处理。

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

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

4. 扩展性（能够在服务器负载时添加更多节点）

默认情况下，AWS 提供高度可扩展性，为每个服务设置了某些限制。请充分了解这些限制，在非常大规模的情况下才会超出限制（可以通过联系 AWS 支持团队来增加限制）。

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

如上所述，这些 AWS 服务由 AWS 自身管理。只要您在限制范围内，就没有任何问题需要担心。

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

- Keet Sugathadasa