本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
实施部分批处理响应的最佳实践
以下是为 Amazon SQS 事件源配置部分批量响应的最佳
-
配置死信队列,以避免在无服务器应用程序的架构中产生 snowball 反模式。有关更多信息,请参阅本指南的 Avoiding snowball anti-patterns。
-
配置 Lambda 函数事件源映射,使其仅显示失败的消息。为此,在配置事件源映射时,必须在FunctionResponseTypes列表ReportBatchItemFailures中包含该值。有关更多信息,请参阅《AWS Lambda 开发者指南》中的实现部分批量响应。
-
定义您希望消息在发送到死信队列之前移至源队列的次数。通过确定可能的故障原因以及预计恢复时间,确保您定义的值符合应用程序的用例。要定义重试次数,您必须在源队列上配置该maxReceiveCount值。RedrivePolicy有关更多信息,请参阅 Amazon SQS API 参考SetQueueAttributes中的。另请参阅 AWS 博客上的 Introducing Amazon Simple Queue Service dead-letter queue redrive to source queues
。 -
确保您的 Lambda 函数代码是幂等性
的,并且能多次处理消息。这将准备函数的代码,以支持 Amazon SQS 消息批处理中的单个任务。一个好的起点是将其ReportBatchItemFailures纳入您的事件源映射配置。有关详细信息,请参阅《AWS Lambda 开发人员指南》中的报告批处理项目失败。另请参阅如何防止亚马逊SQS消息多次调用我的 Lambda 函数? -
考虑使用诸如aws-embedded-metrics
或 Powertools for AWS Lambda (Python) 之类的工具 。这些工具可帮助您将业务指标合并到函数代码中,以跟踪失败的作业以及这些作业的详细信息。 -
如果您将此功能与 First-In-First -Out (FIFO) 队列一起使用,则您的函数应在第一次失败后停止处理消息,并返回所有失败和未处理的消息。
batchItemFailures
这有助于保留队列中消息的顺序。
注意
要跟踪使用部分批处理的应用程序的整体性能,需要使用代码级性能跟踪。配置部分批处理后,无论批处理的结果如何,Lambda 函数的调用几乎总是成功的。
避免 snowball 反模式
Lambda 和 Amazon SQS 无法控制上游微服务写入亚马逊队列的消息。SQS如果存在无法处理的消息,除非配置了单独的死信队列,否则 Lambda 会将这些未处理的消息返回到源 Amazon SQS 队列。然后,Lambda 函数将在接下来的每个 Amazon SQS 消息批次中重试这些未处理的消息,失败并返回队列进行重试。如果不存在死信队列,则返回到 Amazon 队列的未处理消息数量最终会超过SQS队列中的有效消息数量。
这种类型的 snowball 反模式(每次连续调用 Lambda 函数都会使问题变得更糟)可能会导致以下问题:
-
用户体验不佳,因为任务处理时间比平时长得多,或者根本不处理
-
成本增加与 Amazon SQS 队列中消息数量和消息重试次数呈指数级增长成正比
-
如果函数对其调用请求没有限制,则会降低应用程序或整个 AWS 账户的 Lambda 计算能力
为了避免在 Amazon 中配置部分批量响应时创建雪球反模式SQS,最好同时创建死信队列。这个单独的队列可以存储未成功处理的消息,并帮助您更好地管理应用程序未处理消息的生命周期。
有关说明,请参阅《A mazon SQS 开发者指南》中的配置死信队列(控制台)。