可见性超时、DLQ 与长轮询

当消费者从 SQS 接收消息时，该消息会在一段称为可见性超时的时间内对所有其他消费者隐藏。在此期间，消费者处理消息，然后将其删除。如果消费者崩溃或未能及时完成处理，可见性超时到期，消息会重新变为可见，其他消费者便可以获取它。这是 SQS 实现至少一次投递保证的核心机制。

默认可见性超时为30 秒，可设置为 0 秒至12 小时。请将其设置为明显超过预期最长处理时间的值——如果处理最多需要 2 分钟，请将超时设置为至少 3 至 4 分钟。您还可以使用 change-message-visibility 针对单个回执更改超时时间；当消费者发现处理某条特定消息需要更多时间时，这非常有用。

将超时设置得过短会导致消息在消费者完成处理前重新出现，从而引发重复处理。将超时设置得过长时，如果原消费者无提示地失败（例如 EC2 实例崩溃且未进行正常清理），会延迟其他消费者获取消息。最佳超时时间应略长于处理时间的第 99 百分位，同时足够短，以便从消费者故障中快速恢复。请监控 ApproximateNumberOfMessagesNotVisible CloudWatch 指标，以发现超时问题。

死信队列（DLQ）是一个独立的 SQS 队列，消息在处理失败达到可配置次数（即 maxReceiveCount）后会被发送到这里。当消息的接收次数超过 maxReceiveCount 时，SQS 会自动将其移动到 DLQ。DLQ 可以防止有毒消息（始终处理失败的消息）无限期阻塞队列。修复处理错误后，您可以检查、调试并重新处理 DLQ 中的消息。

DLQ 就是一个普通的 SQS 队列（Standard 源队列对应 Standard，FIFO 源队列对应 FIFO）。您需要在源队列上配置重驱动策略（Redrive Policy），以指定哪个队列是 DLQ，以及 maxReceiveCount 阈值。请确保 DLQ 的保留期更长，超过源队列的保留期——消息到达 DLQ 时已经较晚，您需要留出调查时间，避免消息过期。

请针对 DLQ 的 ApproximateNumberOfMessagesVisible 指标设置 CloudWatch 告警。任何进入 DLQ 的消息都表示存在需要处理的失败。请将告警配置为触发 SNS 通知，立即通知值班工程师。请将每条 DLQ 消息都视为需要调查的错误——不应让 DLQ 消息在无人察觉的情况下不断累积。修复错误后，请使用 DLQ 重驱动将消息发送回源队列重新处理。

修复导致处理失败的错误后，请使用 SQS DLQ 重驱动将消息从 DLQ 移回源队列重新处理。控制台提供内置的重驱动功能。您可以按消息属性进行筛选，只重新处理特定消息。如果需要自定义筛选逻辑，也可以编写 Lambda 函数轮询 DLQ，并将消息转发回源队列。

默认情况下，SQS 使用短轮询：receive-message 调用会随机抽取部分服务器并立即返回，即使当前没有可用消息。这会产生大量空响应并浪费 API 调用。长轮询会等待消息到达，最长20 秒后才返回空响应。长轮询可以显著降低成本（减少 API 调用次数）并降低延迟（消息到达后会立即被接收，比下一轮轮询最多提前 20 秒）。

您可以在队列级别启用长轮询（应用于所有接收调用），也可以按请求启用。对于大多数应用，建议在队列级别将 ReceiveMessageWaitTimeSeconds 配置为 20。当 Lambda 使用 SQS 作为事件源时，会自动使用长轮询。对于基于 EC2 的消费者，请在 receive-message 调用中设置 WaitTimeSeconds。

SQS 消息可以携带消息属性——与消息正文分离的元数据键值对。属性具有类型（字符串、数字、二进制）和值。当 SQS 订阅 SNS 主题时，您可以使用应用于消息属性的SNS 订阅筛选策略，仅将相关消息路由到各个队列。如果不进行筛选，每个 SQS 订阅者都会收到 SNS 发布的每条消息，无论内容是什么。

延迟队列会让每条新消息在发送后的一段延迟时间内保持不可见，延迟时间为 0 至 15 分钟。这适用于消费者不应立即处理消息的工作流，例如先等待某个依赖流程完成。您还可以在发送调用中使用 DelaySeconds 设置单条消息的延迟，该设置会覆盖队列级别的延迟。注意：FIFO 队列不支持延迟队列。

测试您对本课 AWS Solutions Architect (SAA-C03) 概念的理解。

在本课中，您学习了：可见性超时会在消息处理期间将消息对其他使用者隐藏，从而实现至少一次投递；如果使用者失败，系统会自动重新投递。死信队列会捕获反复失败的消息，以便在修复错误后进行调试和重新处理；长轮询（最长等待 20 秒）相比短轮询可以降低 API 成本和延迟。接下来，我们将探索 SNS 主题和扇出架构。