我正在尝试找到一个好的队列服务器/消息代理，它可以让我将作业推送到队列，但也可以：
我知道很多名字，如RabbitMQ，ActiveMQ，Kafka，但我想听听现实生活中的经验，而不仅仅是我已经读过的文章。
我也有同样的要求，我评估了不同的Queue服务，如RabbitMQ和Apache Kafka，但所有这些服务，要求我们维护自己的服务器并对其进行管理。这样做的问题是维护我们自己的服务器成本很高，我们需要自己管理它的可伸缩性（除非我们使用提供可伸缩性的服务器）。
然后我切换到AWS SQS，AWS Lambda，这是我的要求的理想选择。主要优点是，它完全无服务器，AWS将处理它的可扩展性。我们需要跟踪每个服务的限制，只有在我们扩展到非常大的水平时才会受到影响。
现在，让我们来看看这个解决方案将如何满足您的要求。
当SQS收到消息时，您可以调用Lambda函数（作业A）并调用（作业B）以确保维护订单。在没有Lambdas的情况下可以使用类似的方法，您可以使用它在每个作业完成后按照所需的顺序引导消息。使用AWS SQS和Lambda的优点是，SQS提供了调用lambdas（2018年6月引入的功能）的功能，我们不需要每次轮询队列。
如果订户失败，您可以将消息发送到死信队列（DLQ），这是另一个SQS队列，用于存储接收方失败的消息。 （见this link）。有了这个，您可以使用1中提到的类似方法，您可以让DLQ中的消息单独处理。
SQS会在一段时间内保留您的消息。您可以指定要在队列中存储消息的时间段。如果您想要在一段时间后不会过期的硬持久性，请考虑将其存储在数据库或其他存储机制（如S3）中。
默认情况下，AWS提供高可伸缩性，其中为每个服务设置了某些限制。充分意识到这些局限性，如果我们进入一个非常大的规模，它只会超过它。 （这可以通过联系AWS支持团队来增加）
如上所述，这些AWS服务由AWS本身管理。因此，只要你保持在极限范围内，就没有什么可担心的了。
您在问题中提到的所有解决方案都很好，但它的用处取决于用例场景。根据提到的要求，AWS SQS将是这种情况的理想选择。