月度批量发票PDF生成发送架构合理性及技术问题咨询

一、架构合理性判断 #

你的整体架构方向是可行的——基于CronJob触发批量任务，用SQS做任务缓冲与分发，Lambda负责具体的PDF生成，符合AWS事件驱动批量处理的最佳实践。但现有设计存在几个细节问题需要优化，以下是针对性解答和建议：

二、核心疑问解答 #

1. Lambda发送SQS消息的超时/时长限制问题 #

不要采用串行或全量并行的极端方式，改用分段批量+并发控制的方案：

• 第一个Lambda拉取数据时，将50万条数据拆分为多个小批次（比如每批次1000条），使用SendMessageBatch接口（每次最多发10条），同时限制并发请求数（比如一次发起20个批量请求，共200条），既保证效率，又能控制单Lambda的执行时间在15分钟上限内。
• 如果单Lambda仍无法处理完所有数据分发，改用Step Functions编排流程：第一步分页拉取数据并拆分分段，第二步并行调用多个Lambda实例分别处理不同数据段的消息发送，彻底规避Lambda的时长限制。

2. SQS消息存储上限 #

• 标准队列：默认配额为120万条消息，可通过AWS支持申请提升至无限量（取决于你的存储资源），50万条完全在默认覆盖范围内。
• FIFO队列：默认配额为10万条，同样可申请提额，但你的场景无需FIFO的顺序保障，用标准队列即可。

3. 避免重复生成PDF的幂等性处理 #

基于账单编号的唯一性，用DynamoDB的条件写操作实现幂等校验：

• 在PDF生成Lambda中，先调用DynamoDB的PutItem接口，设置条件表达式：attribute_not_exists(bill_id)（将账单编号设为主键）。
• 只有当该账单编号不存在时，操作才会成功，此时执行PDF生成；若操作失败（返回ConditionalCheckFailedException），直接跳过该任务，无需重复生成。
• 这种前置校验的方式能有效节省计算资源，避免无用的PDF生成操作。

三、架构优化建议 #

1. 数据拉取阶段优化
   • 不要一次性拉取50万条数据，改用分页查询（比如每次拉1万条），减少Lambda内存占用，避免因内存不足崩溃。关系型数据库用LIMIT/OFFSET或游标分页，DynamoDB用Query的分页功能。
2. SQS配置优化
   • 启用死信队列（DLQ），将处理失败的消息（如PDF生成报错）转发至DLQ，便于后续排查和重试，避免消息丢失。
   • 设置合理的消息可见性超时（建议30分钟），确保Lambda有足够时间处理单条消息，避免因处理超时导致消息被重新分发引发重复处理。
3. PDF生成Lambda优化
   • 提高Lambda内存配置（如调整至2048MB），AWS Lambda的CPU与内存成正比，更高的内存能加快PDF生成速度。
   • 若PDF生成依赖外部服务，设置合理的超时时间，避免无意义的等待。

四、同类场景实践参考 #

• 用Step Functions编排百万级数据的分段处理流程，解决Lambda时长限制问题，是AWS生态中批量任务调度的标准方案。
• SQS+Lambda配合DynamoDB条件表达式实现幂等性，是事件驱动批量任务处理的通用模式，广泛应用于账单生成、报表导出等场景。
• 若后续数据量持续增长，可考虑结合ECS/EKS运行批量处理容器，Lambda仅作为任务触发和调度器，平衡成本与处理性能。

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