Lambda复用单SQS实现多下游推送的架构及故障处理咨询

你担心的复用现有SQS与Lambda承载多场景推送时的故障影响确实会发生：
如果把所有下游推送逻辑都耦合在同一个Lambda函数中，只要任意一个下游推送流程失败，整个Lambda调用就会被标记为执行失败，对应SQS消息会触发重试，超过最大重试次数后进入死信队列（DLQ）。后续重驱动DLQ中的消息时，这条消息绑定的所有推送逻辑（包括之前已经推送成功的下游）都会全部重复执行，很容易造成下游数据重复写入、状态错乱等问题。

方案1：复用现有SQS+Lambda，在单函数内堆所有推送逻辑 #

这个方案强烈不推荐，核心问题有几个：

• 故障完全无隔离：单个下游服务抖动（比如服务Y接口超时、报错）会直接阻塞所有推送链路，原本正常推送给服务X的消息也会被反复重试，甚至堆积进DLQ，造成正常业务中断
• 问题排查与恢复成本极高：DLQ中的消息无法标记具体是哪个下游推送失败，重放时无法精准重试失败链路，要么全量重放造成重复推送，要么只能人工逐条筛消息，恢复效率极低
• 扩展风险高：后续新增服务Z的推送逻辑时，必须修改现有Lambda的代码逻辑，需要回归测试所有已上线的推送链路，很容易因为改代码引入故障影响老业务
• 无法适配差异化规则：不同下游如果需要不同的重试次数、超时时间、限流策略，在同一个Lambda、同一个SQS队列的架构下根本无法实现

方案2：每个业务场景独立部署SQS队列+Lambda函数 #

这个方案是可行的，核心优势：

• 故障完全隔离：每个下游链路的SQS、Lambda、DLQ、监控告警都是独立的，单个下游出问题不会影响其他链路运行
• 运维简单：每个链路的DLQ只存对应下游推送失败的消息，重放时只会执行对应下游的推送逻辑，完全不会出现重复推送给其他已成功下游的问题
• 扩展灵活：新增下游时不会影响已上线的老链路，不用改老代码
  唯一的所谓“缺点”是需要多创建几个Serverless资源，实际上SQS和Lambda都是按实际用量计费，没有额外的常驻运维成本，整体开销和单Lambda堆逻辑几乎没有区别。

不用做二选一，用SNS原生的消息订阅+过滤能力就能实现最低成本的架构扩展，完全不需要改动现有已上线的链路：

1. 保留现有推服务X的整套架构不动，现有SQS订阅、Lambda逻辑、DLQ配置完全不用改，零侵入不影响线上业务
2. 新增下游（比如服务Y、未来的服务Z）时，直接给现有SNS主题新增独立的SQS队列订阅：
   • 如果不同下游需要消费不同类型的事件，可以直接给SNS订阅配置消息过滤规则，不需要的事件根本不会投递到对应SQS，省掉额外的消息过滤成本
   • 每个新增的SQS队列单独绑定对应Lambda函数，配置独立的重试策略、可见性超时、DLQ、告警规则
3. 所有链路共用同一个SNS主题，不需要额外转发组件，完全复用现有基础设施

注意：不管采用哪种架构，所有下游服务都必须实现幂等处理逻辑。SQS本身是至少一次投递模型，哪怕是独立队列架构，极端场景下也可能出现重复投递，下游靠幂等性防重写是最基础的保障。

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