使用AWS向SQS批量发送消息后，关联Lambda丢失部分消息请求的问题解决

结合你描述的功能现象、参数配置与监控数据，你使用的是FIFO类型的SQS队列，SQS侧发送、接收计数均正常但Lambda仅处理部分消息的问题，可按以下优先级排查解决： #

1. 事件源映射的批量拉取窗口配置异常 #

• FIFO队列与Lambda的关联事件源，默认会开启批处理等待窗口：当拉取到的消息数量未达到配置的BatchSize阈值时，事件源会持续等待，直到凑够设定的批量大小，或等待窗口超时才会触发Lambda执行。
• 若你短时间内并发发送的消息数较少，事件源会将消息暂存到拉取缓冲区，等窗口到期后才会统一推送给Lambda。刚发完消息立刻查询CloudWatch日志，就会误以为消息丢失。
  • 排查与解决操作：
    • 打开关联Lambda的事件源配置页面，确认BatchSize设置，对于实时处理场景可将BatchSize调整为1，关闭批量等待逻辑
    • 若开启了批处理窗口，适当缩短窗口超时时间（建议不超过1秒）

2. 消息排队导致的处理延迟 #

• FIFO队列的核心规则是：同一个MessageGroupId下的消息严格有序，全局仅会分配一个Lambda实例拉取该分区下的消息，不会对同一Group的消息做并发处理。
• 如果你短时间内将所有并发发送的消息都归到同一个testGroup分区，且Lambda配置了较小的预留并发额度，所有消息会排成单条处理长队列，按顺序逐批触发Lambda执行。
• 你在SQS控制台看到的“累计接收消息数”，仅代表事件源映射成功调用ReceiveMessage接口拉取消息的次数，不代表这些消息已经全部触发Lambda完成执行并输出日志——拉取到的消息会先进入事件源调度队列，按并发额度依次触发函数。
  • 排查与解决操作：
    • 不要将高并发发送的消息全部归到同一个MessageGroupId下，可按业务维度拆分GroupId（如用户ID、请求ID维度），每个GroupId可独立获得一个Lambda并发执行实例，线性提升处理速度
    • 确认Lambda的并发预留配置，不要将并发数设置得过小，为队列预留足够的处理容量
    • 将队列的可见性超时设置为Lambda最长执行时间的2倍以上，避免未处理的消息因超时被重复放回队列

3. 日志上报的遗漏问题 #

• 你的Lambda代码设置了context.callbackWaitsForEmptyEventLoop = false，这个配置的作用是：一旦函数事件循环中没有等待的异步任务，就立刻冻结函数实例，不再等待后续异步任务完成。
• 如果你使用的自定义wapper是异步包装逻辑，日志上报的异步请求还未发送到CloudWatch，函数就已经因为空事件循环被冻结，就会出现日志缺失，看起来像消息未被处理。
  • 排查与解决操作：
    • 初次排查时先去掉自定义wrapper逻辑，用原生Lambda handler实现日志输出，跑一轮并发测试确认日志是否能完整上报
    • 检查CloudWatch日志组的保留周期，避免因日志过期被自动清理造成的“消息丢失”假象

4. 消息去重逻辑的误触发 #

• 虽然你按FIFO队列要求为每条消息配置了MessageDeduplicationId，但需核对实际代码逻辑是否真的为每条消息生成了全局唯一的去重ID：如果并发发送逻辑复用了全局的params对象，没有在每次调用时重新生成独立的uuid值，SQS侧就会将后续发送的重复ID消息判定为重复内容，通过去重逻辑直接丢弃，不会进入消费队列。
  • 验证方式：在SQS控制台的监控面板中，查看SentMessageDeduplicated指标值，如果该值异常升高，即可确认是去重逻辑导致的消息丢失。
  • 排查与解决操作：
    • 编写并发发送逻辑时，不要复用全局params对象，每次调用sendMessage时单独生成独立的MessageDeduplicationId，确保每条消息的去重ID在队列去重窗口时间内全局唯一

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