如何处理 Amazon SQS 中的死信队列？

Question

我正在为我的一个项目使用事件驱动架构。 Amazon Simple Queue Service 支持处理故障。

如果一条消息没有被成功处理，它就不会到达我从队列中删除消息的部分。 如果它是一次性的失败，它会被优雅地处理。 但是，如果它是一条错误消息，它就会进入 DLQ。

我的问题是以后 DLQ 应该怎么办？ DLQ 中有数千条这样的消息。 他们应该如何处理？

我很想听听一些组织中的一些现实生活中的例子和工程流程。

Answer 1

“这取决于！”

消息将被发送到死信队列，因为某些事情没有按预期发生。 这可能是由于数据问题、超时或编码错误造成的。

你应该：

• 开始检查进入死信队列的消息
• 尝试并重新处理消息以确定失败的根本原因（但有时它是您无法重现的随机失败）
• 找到原因后，更新系统以处理该特定用例，然后转到下一个原因

常见原因可能是数据库锁定、网络错误、编程错误和损坏的数据。

设置某种监视可能是个好主意，这样有人可以更快地进行调查，而不是让它累积成数千条消息。

Answer 2

如您所说，移动到 DLQ 的消息被认为是错误的。

如果由于代码中的错误等导致消息错误，您应该在修复错误后将这些 DLQ 消息重新驱动到源队列。 以便他们有另一次机会被重新处理。

如果您已经将源队列的 maxReceiveCount 配置为 3 或更多，则“临时”错误消息不太可能被移动到 DLQ。 使用此重试配置可以绕过大部分临时问题。

最终 DLQ 也是一个普通的 SQS 队列，最多可保留消息 14 天。 即使那里有成千上万条消息，它们也会消失。 此时，有两种选择：

• DLQ 中的消息“确实”是错误的。 因此，请查看指标、消息和日志以确定根本原因。 如果没有要修复的错误，则意味着您在 DLQ 中保留了不需要的数据。 所以在 14 天内丢失它们并没有错。 如果存在错误，请修复它，只需将消息从 DLQ 重新驱动到源队列。
• 您不想通过消息进行调查以确定失败的原因是什么，并且您只想出于历史原因保留消息数据（天知道为什么）。 您可以创建一个 lambda function 来轮询消息并保存在所需的目标数据库中。