Lambda达最大并发上限时，SNS触发消息的处理疑问

你问到的这个场景很典型，当SNS主题的消息量超过Lambda的处理能力、Lambda达到并发上限时，消息不会直接丢失，而是遵循一套明确的重试和兜底机制，下面给你详细拆解：

• 节流后的自动重试：当Lambda达到最大并发时，新的SNS触发请求会被Lambda返回Throttled（429）错误。这时SNS不会放弃，会启动指数退避式重试——第一次重试在20秒后，之后每次间隔翻倍（40s、80s……），最长间隔到1小时，总共最多重试100次。也就是说，那些没被及时处理的消息会在后续时间点再次尝试递送给Lambda，直到成功或者重试次数用尽。

• 你的场景具体表现：比如你说的每秒1000条消息、Lambda每秒处理600条，那超出的400条会立刻进入重试队列。后续这些重试消息会和新消息一起竞争Lambda的并发资源，只要Lambda有空闲的并发槽，就会参与处理调度。

• 死信队列兜底：如果你给SNS的Lambda订阅配置了死信队列（可以是SQS队列或者另一个SNS主题），当所有100次重试都失败后，这些未处理的消息会被转发到死信队列里，你可以后续手动排查处理，避免消息永久丢失。

• 优化建议：如果这种高并发积压是常态，光靠重试可能不够，你可以考虑这几个方向：

  • 申请提高Lambda的并发上限（AWS默认有账户级并发限制，可通过控制台提交申请扩容）；
  • 优化Lambda函数的执行效率，减少单条消息的处理时间，提升每秒处理量；
  • 引入SQS做缓冲：让SNS先把消息发送到SQS队列，再由Lambda从SQS拉取处理——SQS天然支持消息积压，你可以通过配置Lambda的批量处理和并发数，更灵活地控制处理节奏。

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