SQS触发的Python Lambda突发卡顿、超时且不删除队列消息如何排查

核心矛盾锚定 #

先把你观测到的反常信号单独拎出来，避开常见的思维误区：

• 最反常的信号不是执行时长飙升，而是SQS消息删除数为0、但Lambda仍有成功执行记录——这才是定位问题的突破口
• 所有异常都是在无配置改动的情况下，跑了约1700条消息后中途出现的
• Lambda执行时长陡增的同时并发数下降，仅存在极少量错误，未超时的任务均显示执行成功，日志无业务报错
• SQS可见消息数长期卡在192条不动，消息接收数跌到极低值

问题本质拆解 #

你最初怀疑的Lambda读取S3超时阻塞队列，并不是当前故障的核心原因：
如果是S3访问慢导致任务触发90秒超时，首先Lambda的执行状态会被标记为错误，而非你观测到的“大部分任务执行成功”；其次如果是消息处理失败导致删不掉，SQS的可见消息数会随着消息反复重入持续上涨，完全匹配不上你看到的“消息删除数为0、可见数稳定卡在192条不动”的表现。

从观测的异常信号倒推，故障的完整触发链路基本是这样的：

• 你之前为了恢复运行，对SQS触发器做过禁用、重新启用操作，这个操作大概率导致Lambda对应的SQS事件源映射状态出现损坏
• 内置SQS触发器的工作逻辑很简单：只要Lambda函数返回执行成功，Lambda平台会自动帮你删除对应队列的消息，根本不需要业务代码主动调用删消息接口。当事件源映射状态损坏后，就会出现“平台能正常从队列拉取消息、触发Lambda执行，但拉取完成后触发消息删除的链路断裂”的奇怪状态
• 因为删除链路断了，被拉取过的消息过了SQS的不可见超时时间后，会原封不动回到可见队列，导致队列里永远卡着那192条消息反复被拉取，最终表现为可见消息数长期稳定不动、消息接收数跌到极低值
• 这些被反复拉取的重复消息，会重复触发Lambda的全流程业务逻辑：读S3文件、生成YAML、上传新文件、写入RDS记录。大量重复的RDS写操作会快速占满RDS实例的数据库连接池
• 当RDS连接数被占满后，后续的Lambda执行在建立RDS连接的阶段就会进入长时间等待状态，直接表现为单条Lambda的执行时长从原来的几秒逐步拉长，逼近90秒的超时阈值
• 因为单条执行的时长被拉长，同样的并发额度下，正在运行的Lambda实例都卡在等待RDS连接的状态，没有多余资源拉取新的消息，自然就出现了函数并发数下降的表现
• 你看到的少量错误，就是那些等待RDS连接时间超过90秒的执行。因为超时是Lambda平台层抛出的，业务日志里只会记录通用的超时信息，不会有具体的业务报错；剩下的没超时的执行，哪怕是重复处理旧消息，只要业务代码没抛出异常，都会被标记为执行成功——这和你观测到的“日志无报错、未超时任务均显示成功”的现象完全吻合

可落地的排查操作步骤 #

• 先进入Lambda的触发器配置页，查看SQS事件源映射的状态日志，确认是否存在权限类错误、内部状态错误。如果存在状态损坏，直接删除原有触发器，重新创建一次事件源映射，即可修复拉取-删消息链路断裂的问题
• 对照RDS的监控指标，检查当前实例的连接数是否已经触达最大连接数配置。如果连接被占满，可先临时扩容连接数上限，或重启RDS实例释放僵尸连接
• 在修复事件源映射之前，先把当前SQS队列里堆积的192条可见消息临时移到备份队列，避免触发器恢复后反复处理重复消息，再次占满RDS连接
• 检查Lambda的执行角色权限，确认是否对当前SQS队列持有sqs:DeleteMessage、sqs:GetQueueAttributes的操作权限，排除权限策略被SCP、权限边界意外拦截的可能性

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