批大小为1、预留并发为1的Lambda长轮询SQS消息丢失问题求助

当前20%-30%消息未处理、最终丢失的核心原因如下：

• Lambda预留并发为1、单批仅处理1条消息，单实例处理上限约为<1条/分钟，若消息生产速度高于该值会直接导致队列积压，积压超过4天的消息会被SQS自动删除
• Lambda侧2次重试+SQS侧5次最大接收的规则存在逻辑重叠：同一条异常消息会被反复拉取、重试，长期占用唯一的并发资源，导致正常消息无法被调度处理
• 若消息处理耗时波动大，可能出现消息还未处理完成就因到达可见性超时时间被重新放回队列，重复占用拉取额度，甚至最终触发最大接收次数流入DLQ被误判为丢失

• 优先排查消息流向：先核查绑定的死信队列是否存在未处理消息，同时拉取Lambda运行日志确认未处理消息的报错原因，区分是业务逻辑处理失败、Lambda运行超时还是事件源调度异常
• 统一重试管控逻辑：将Lambda的Retry Attempts参数调整为0，取消Lambda侧的内置重试，所有重试逻辑完全由SQS的Maximum Receives参数统一管控，减少异常消息重复占用并发的时间
• 动态调整消息可见性：在Lambda代码中新增ChangeMessageVisibility接口调用逻辑，若业务处理耗时预计超过当前消息剩余可见时间，主动延长可见性时长，避免消息未处理完就被放回队列重复拉取
• 优化队列参数配置：若存在常态化消息积压场景，可将SQS的消息保留周期从4天上调至最高14天，避免消息还未被消费就因过期被自动删除；同时可根据实际单条消息最长处理耗时，将Visibility Timeout调整为「单条消息最大处理耗时 * 2」的冗余值即可，不需要设置过长的不可见时间，避免失败的消息无法被快速重新调度
• 异常消息提前拦截：配置SQS队列深度、消息接收次数阈值告警，当单条消息接收次数超过3次时，可通过额外的旁路逻辑先将异常消息转移到备用队列，避免长期占用唯一的Lambda并发资源，影响正常消息消费
• 优化处理逻辑效率：在业务允许的前提下优化Lambda代码逻辑，尽可能降低单条消息的处理耗时，提升单并发下的消息处理吞吐，降低积压概率

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