我也有同样的需求，我评估了不同的队列服务，比如rabbitmq和apachekafka，但是所有这些服务都需要我们维护和管理自己的服务器。这样做的问题是维护我们自己的服务器的成本很高，我们需要自己在可伸缩性上管理它（除非我们使用提供可伸缩性的服务器）。
然后我切换到aws sqs，使用aws lambda，这非常适合我的需求。主要的优点是，它完全没有服务器，aws将处理它的可伸缩性。我们需要跟踪每个服务中的限制，只有当我们扩展到非常大的级别时，这些限制才会受到影响。
现在，让我们看看这个解决方案将如何满足您的需求。
在作业之间建立依赖关系（例如，仅在作业a完成后运行作业b）
当sqs接收到消息时，可以调用lambda函数（作业a）并让该函数调用（作业b），以确保保持顺序。在没有lambda的情况下也可以使用类似的方法，在lambda中，可以在每个作业完成后按照所需的顺序引导消息。使用aws sqs和lambda的优势在于，sqs提供了调用lambdas的功能（这是2018年6月引入的一个特性），在这里我们不需要每次轮询队列。
如果订阅服务器未能执行任务，则允许重新运行任务（不从订阅服务器将其推回队列）
如果订户失败了，您可以将消息发送到死信队列（dlq），它是另一个sqs队列，用于存储接收方失败的消息(请参见此链接）。有了它，您可以使用类似于1中提到的方法。您可以让dlq中的消息单独处理。
持久性（在服务器重启等情况下）
sqs会将您的消息持续一段时间。您可以指定要在队列中存储消息的时间段。如果您想要硬持久性（在一段时间后不会过期），请考虑将其存储在数据库或其他存储机制（如s3）中。
扩展（以便在服务器加载时能够添加更多节点）
默认情况下，aws提供了高可扩展性，其中为每个服务设置了某些限制。要充分认识到这些局限性，如果我们进入一个非常大的范围，它只会超过(可通过联系aws支持团队来增加）
优势：aws中的托管解决方案
如上所述，这些aws服务由aws自己管理。所以没什么好担心的，只要你在限制之内。
您在问题中提到的所有解决方案都是好的，但是它的有用性取决于用例场景。根据上述要求，aws sqs将是该场景的理想选择。