使用 AWS 构建任务处理的最佳实践是什么？

如何解决使用 AWS 构建任务处理的最佳实践是什么？

我想知道如何配置 AWS Lambda、SNS 和 SQS 来处理后台任务。

我想到了三种方式。

选项 1。一个叫做consumer的函数可以通过从队列中接收任务来执行worker。

选项 2。将所有任务发送到 SNS。一名工人和一名 SQS 从 SNS 接收和工作。

选项 3。从APP直接将任务转发给一个SQS和一个lambda。

最关心的是是在应用中直接调用Lambda，还是通过SQS或SNS使用任务消费者。

我的想法来自Triggering multiple lambda functions from one SQS trigger

解决方法

这取决于您当前和未来的要求：

选项 1：选择消费者 lambda 将允许您在事件中添加验证和操作。 但是您的消费者 lambda 将一直运行，直到您的工作 lambda 运行为止。

选项 2：SNS 使您可以灵活地在未来添加新事件和新订阅者，并且您的应用程序只需处理 SNS。

选项 3：如果您确定将来不会有此类其他 lambda。在这种情况下，您的应用需要配置哪种类型的事件将转到哪个 SQS。

您可以根据您的要求选择任何选项，但我建议您选择选项 2，因为您的应用程序需要仅将通知推送到 SNS（单一集成）。在 SNS 中，您可以为不同类型的事件添加过滤器。 您也可以从 SNS 直接触发 lambda。

如果您的应用中不需要 lambda 函数的输出，则应使用 SNS/SQS 进行异步处理。

,

典型的模式是：

• 将作业/任务推送到 Amazon SQS 队列
• 配置 AWS Lambda 函数以订阅到 SQS 队列
• Lambda 会自动为 SQS 队列中的每条消息执行 Lambda 函数

我猜这与您的选项 1 相符，但 AWS Lambda 服务充当触发各个 Lambda 函数的“消费者”。

如果不同类型的输入（例如三个不同的任务）需要不同的 Lambda 函数，则创建 3 个单独的队列，每个队列都链接到自己的 Lambda 函数（您的选项 3）。

在中间插入 Amazon SNS（如选项 2 所示）可以更轻松地“分叉”信息，例如为每条消息添加另一个订阅者，以防它们需要并行处理。否则，没有必要。