监听S3事件的Lambda收齐3个文件后触发API的方案咨询

• 计数操作非原子，并发下必然出现数据错误：你现在用的「先查询当前计数值→判断是否到阈值→加1写回」是三个独立步骤，Lambda默认是并发执行的，只要两个S3事件同时触发，就可能读到同一个计数值，各自加1后写回，最终计数比实际上传数小，永远凑不到3；也可能多个执行流同时读到计数为2，重复触发文件处理API。
• 没兼容S3事件的投递语义：S3事件通知是至少一次投递，同一个文件上传成功，可能重复给Lambda发多次通知，没有去重逻辑的话计数会虚高，3个文件没传齐就提前触发处理。
• 主键设计有硬伤：仅用日期作为计数项的区分维度，根本没法区分同一天内多批次上传的文件组，不同批次的事件会共用同一个计数器，数据直接串扰。
• 没有状态标记，异常场景下逻辑混乱：计数到3触发API之后，没有标记该批次已处理，后续遇到重复事件、Lambda重试事件，会重复调用API；如果触发API的过程中Lambda报错退出，重试时也会重复发起调用。
• 缺少兜底机制：没考虑文件漏传、上传失败的场景，计数器会一直卡在某个数值，形成脏数据，后续同维度的新批次上传时会直接读错计数。

• 先调整DynamoDB表设计和核心更新逻辑：
  • 主键不要只用日期，根据业务维度加批次区分度：如果是固定每日一批3个文件，主键用业务日期+业务场景标识；如果一天有多批次，直接给每批文件提前分配唯一批次ID，要求上传时文件名携带该ID，用批次ID作为主键。
  • 废弃「先查后改」的逻辑，直接用DynamoDB的UpdateItem原子更新能力：通过ADD Count :incr操作直接给计数加1，更新响应里会直接返回更新后的最新计数值，全程不存在并发读写冲突。
  • 表内额外加三个字段：已上传文件集合（StringSet类型，存每个文件的唯一标识，建议用S3对象Key+ETag拼接）、处理状态（枚举值：待收集/处理中/处理完成/处理失败）、TTL过期时间。
• 内置事件去重能力：每次收到S3事件，先提取对象Key+ETag作为文件唯一标识，原子更新时同步把该标识加入已上传文件集合——DynamoDB的集合类型自带去重能力，如果该标识已经存在于集合中，直接终止当前逻辑，不对计数做任何修改，从根源上解决重复事件导致的计数虚高问题。
• 加触发锁避免重复调用：当原子更新返回的计数值等于3时，不要直接调用API，先发起一次带条件的更新：将处理状态从「待收集」修改为「处理中」，更新条件为当前状态仍为「待收集」。如果条件更新失败，说明其他并发执行流已经拿到了触发权，直接退出即可；如果更新成功，再发起文件处理API调用，调用成功后将状态改为「处理完成」，调用失败则将状态回滚为「待收集」或标记为「处理失败」留待后续重试。
• 增加异常兜底：给每个计数项设置合理的TTL，比如超过业务约定的文件上传截止时间2小时还没收齐3个文件，自动触发告警通知运维排查漏传问题，到期后TTL自动清理脏数据，避免影响后续批次的计数逻辑。

补充：如果业务允许一定的处理延迟，可以给S3事件配置EventBridge延迟投递，比如设置5分钟的延迟窗口再推送给Lambda，能减少短时间内事件并发的概率，但这只是辅助优化，核心还是要把原子更新、去重、状态锁的逻辑做扎实。

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