AWS SQS消息删除后仍重现的问题排查求助

针对你遇到的SQS消息删除后重现的问题，可按以下方向逐一排查：

• 确认可见性超时的实际生效情况

  • 检查ChangeMessageVisibility的调用是否成功：在设置30分钟可见性超时的代码处，增加异常捕获和日志输出，确认该操作没有因为网络、权限或SQS限流失败。如果该调用失败，消息会沿用默认的15分钟超时，若处理耗时超过15分钟，消息会提前回到队列。
  • 统计从接收消息到执行删除的总耗时：计算消息被接收后，经过内部逻辑判断、处理，直到调用deleteMessage的完整时长，确认是否超过了最终设置的30分钟可见性超时。若总耗时超时，消息会被其他消费者重新获取，此时你使用旧的receipt handle删除，可能无法影响已重新入队的消息实例。

• 验证receipt handle的有效性和唯一性

  • 确保在整个处理流程中，receipt handle没有被意外修改：比如在序列化、存储或多线程共享时，是否出现字符截断、覆盖等情况。可在删除前打印receipt handle的完整内容，对比接收消息时的原始handle。
  • 注意：调用ChangeMessageVisibility不会改变消息的receipt handle，所以无需重新获取，但要确保始终使用当前消息实例的handle进行操作。

• 排查高负载下的删除操作成功率

  • 检查删除操作的异常捕获逻辑：确认代码中是否捕获了SqsException等可能的异常，是否存在删除调用失败但未被感知的情况（比如网络抖动、SQS临时限流）。
  • 查看SQS的CloudWatch指标：
    • 对比NumberOfMessagesDeleted指标与代码中执行删除的次数，若指标数值更少，说明有部分删除请求未成功。
    • 检查APIErrorRate指标，确认是否存在删除相关的API错误。

• 检查处理逻辑中的重复场景

  • 确认是否存在消息被重复接收的情况：比如可见性超时过期后，消息被其他消费者获取，而原处理线程仍在运行，最终删除的是旧的消息实例，但新的实例已经进入队列等待处理。
  • 若处理耗时可能超过30分钟，需增加周期性延长可见性超时的逻辑：比如每25分钟调用一次ChangeMessageVisibility，将超时再次延长30分钟，避免消息提前回到队列。

• 验证队列配置的特殊行为

  • 确认队列未启用延迟队列或其他特殊配置：虽然非FIFO队列默认无此类配置，但需排查是否有自定义的队列属性导致消息被重新推送。
  • 检查是否有其他消费者服务在处理同一队列：若其他消费者存在未正确删除消息的情况，也可能导致消息重复出现。

内容的提问来源于stack exchange，提问作者Spartacus