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