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

Question

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

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

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

Answer 1

在评估不同的Queue服务（例如RabbitMQ和Apache Kafka）时，我也有相同的要求，但是所有这些服务都要求我们维护自己的服务器并进行管理。这样做的问题是维护自己的服务器成本很高，而且我们需要根据可伸缩性自己进行管理（除非我们使用提供可伸缩性的服务器）。

然后，我使用AWS SQS切换到AWS Lambda，这对我的要求非常理想。其主要优点是，它完全没有服务器，并且AWS可以处理它的可伸缩性。我们需要跟踪每个服务的限制，只有在扩展到非常大的级别时，这些限制才会受到影响。

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

1. 使作业之间具有依赖性（例如，仅在作业A完成后才运行作业B）

当SQS接收到一条消息时，您可以调用Lambda函数（作业A），然后让该调用（作业B）来确保顺序得到维护。在没有Lambda的情况下也可以使用类似的方法，在该方法中，您可以在每个作业完成后按所需顺序定向消息。使用AWS SQS和Lambda的优势在于，SQS提供了调用lambdas的功能（2018年6月引入的功能），我们不需要每次都轮询队列。

1. 如果订阅者无法执行任务，则允许重新运行任务（无） 将其从订户推送回队列）

如果订户失败，则可以将消息发送到另一个SQS队列，即死信队列（DLQ），该队列存储接收方失败的消息。 （请参见this link）。这样，您可以使用与1.中提到的类似的方法。在该方法中，可以让DLQ中的消息单独处理。

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

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

1. 扩展（以便在服务器加载的情况下添加更多节点）

默认情况下，AWS提供高可伸缩性，其中为每个服务设置了某些限制。要充分意识到局限性，只有在我们大规模发展的情况下，局限性才会超越。 （可以随时通过联系AWS支持团队来增加这一点）

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

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

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