构建基于SQS+Mandrill的邮件微服务：架构痛点与解决方案咨询

先直接给你一套适配需求的架构方案，然后逐个拆解解决你提到的问题：

核心架构思路 #

其他服务直接向**AWS SQS队列（优先选FIFO类型）**发送邮件请求消息，由配置了SQS触发器的Lambda函数自动消费消息、调用Mandrill API发送邮件。全程不需要自建API，其他服务只需拥有SQS的SendMessage权限即可，完全异步且无需额外鉴权逻辑。

问题1：SQS无Lambda触发器？ #

其实AWS SQS（不管标准队列还是FIFO队列）都支持Lambda触发器的，你可能没找到正确的配置路径：

• 打开SQS队列详情页，切换到「触发器」标签
• 点击「创建触发器」，选择目标Lambda函数，配置批量大小、批处理窗口等触发条件
• 确认Lambda的执行角色已拥有SQS的ReceiveMessage、DeleteMessage等必要权限

如果是私有VPC内的队列这类特殊场景，也可以用CloudWatch Events（EventBridge）定期触发Lambda轮询SQS，但触发器是更高效的原生方案。

问题2：避免Lambda超时导致重复发送邮件 #

这个核心是实现幂等性+优化消息处理逻辑：

1. 用SQS FIFO队列：FIFO队列支持「重复消息检测」，如果带相同MessageDeduplicationId的消息5分钟内重复入队，会被自动过滤，从根源减少重复发送。同时「消息分组ID」能保证同组消息按顺序处理，适配事务性需求。
2. 给邮件请求加业务唯一标识：其他服务发消息时，在消息体里带上业务唯一ID（比如订单ID+邮件类型），Lambda处理前先检查这个ID是否已处理过（存在DynamoDB或Redis里，设置合理过期时间），如果已处理直接删除消息，不再调用Mandrill。
3. 优化超时与重试规则：
   • 设置Lambda超时时间大于Mandrill API的最大响应时间（比如Mandrill响应一般1-2秒，Lambda设为10秒足够）
   • 把SQS的可见性超时设为Lambda超时的1.5-2倍，避免Lambda处理中消息被重新分发
   • 给SQS配置死信队列（DLQ），处理失败的消息会进入DLQ，方便后续排查，不会无限重试
4. Lambda处理流程伪代码：

   def lambda_handler(event, context):
       for record in event['Records']:
           message_body = json.loads(record['body'])
           unique_biz_id = message_body['unique_biz_id']
           
           # 检查是否已处理过该请求
           if check_processed(unique_biz_id):
               delete_sqs_message(record['receiptHandle'])
               continue
           
           # 调用Mandrill发送邮件
           try:
               mandrill_client.send(message_body['email_params'])
               mark_processed(unique_biz_id)  # 标记为已处理
               delete_sqs_message(record['receiptHandle'])
           except Exception as e:
               # 致命错误（比如Mandrill API密钥失效）直接转DLQ，非致命错误抛出异常让SQS重试
               if is_fatal_error(e):
                   send_to_dlq(record)
               else:
                   raise e
   

问题3：readMessage单次最多获取10条消息 #

这是SQS的批量拉取限制，完全不影响功能：

• 在Lambda触发器配置里，把「批量大小」设为10（最大值），Lambda每次会收到最多10条消息，批量处理即可
• 如果需要处理更多消息，Lambda可以在当前批次处理完后，主动调用receiveMessage继续拉取（注意控制循环次数，避免超时）
• 这和引导用SES无关，只是SQS的设计限制，用批量处理完全能满足异步邮件的需求

额外优化点 #

• 权限隔离：给每个服务分配最小权限的IAM角色，只允许它们向指定SQS队列发送消息，Mandrill密钥存在Lambda加密的环境变量里，完全隔离
• 监控告警：给Lambda配置CloudWatch告警，监控邮件发送失败率、SQS队列堆积情况
• 消息格式标准化：定义统一的邮件请求格式（比如包含收件人、主题、模板ID、模板参数等），方便Lambda解析和调用Mandrill API

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