无Lambda触发器的AWS SQS DLQ消息为何会变为不可见？

这是预期行为吗？ #

直接给结论：不是DLQ的默认预期行为。DLQ本身不会自动处理消息，消息出现不可见状态，肯定是有外部操作触发了状态变更。

除Lambda触发器外，能让队列消息变不可见的常见情况 #

• 手动/工具调用ReceiveMessage接口：不管是在AWS控制台点击“查看消息”，还是用自定义脚本、第三方测试工具调用SQS的ReceiveMessage接口，只要执行了消息拉取动作，就会默认将消息设置为不可见（时长由队列的VisibilityTimeout参数控制）。你测试中出现的两次不可见，很大概率是有人通过控制台查看过DLQ消息，或是有自动化工具在扫描这个队列。
• 其他AWS服务的集成操作：比如EC2/ECS上的业务应用、CloudWatch的自定义告警动作，甚至部分AWS官方工具，只要它们执行了拉取DLQ消息的操作，都会触发消息不可见状态。
• 监控或归档类工具：如果使用了第三方队列监控工具、消息归档脚本（比如把DLQ消息同步到S3），这些工具定期拉取消息做分析或存储时，也会改变消息的可见性状态。

对你测试场景的具体分析 #

你提到主队列绑定Lambda，消息失败进入DLQ后，唯一的消息两次变不可见，大概率是以下场景之一：

1. 你或团队成员在AWS控制台打开过DLQ的消息列表，控制台的“查看消息”本质就是调用ReceiveMessage，会给消息设置一个短暂的不可见超时（通常30秒左右）。
2. 之前编写的测试脚本、监控脚本未停止，在定期拉取DLQ的消息。
3. 集成的监控服务在自动扫描队列状态时，顺带拉取了消息。

排查根源的方法 #

可以通过CloudTrail的事件日志进行排查：搜索SQS的ReceiveMessage事件，查看事件的调用源（比如控制台IP、调用的IAM角色、服务名称），就能精准定位到触发消息不可见变更的操作方。

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