AWS Lambda触发S3对象推送但指定路径文件不存在问题排查

这是S3和Lambda集成时挺常见的一个坑，我来帮你梳理下可能的原因和对应的解决思路：

1. S3最终一致性导致的“短暂不可见” #

S3对新创建的对象（非覆盖场景）采用最终一致性——简单说就是，对象刚PUT上去，可能还没同步到所有S3节点，这时候事件通知已经发去Lambda了。你的Lambda去读的时候就会报“文件不存在”，但等一会儿再查，对象其实已经在那了。不过你说检查路径时文件确实不存在，这个可能性相对低，但可以排查下。

2. 未完成的分片上传触发了事件 #

如果你的桶允许分片上传（Multipart Upload），当发起上传后没完成或者主动中止了，S3会留着临时分片，但这些分片不会拼成完整的对象。要是你的Lambda事件配置的是s3:ObjectCreated:*（而不是只监听s3:ObjectCreated:Put或s3:ObjectCreated:CompleteMultipartUpload），某些边缘情况就会触发事件，但实际上根本没有完整的对象存在。

3. 对象在Lambda触发后、执行前被删了 #

S3的事件通知是异步的，从对象PUT到Lambda收到事件有个时间差。要是在这个间隔里，对象被其他服务、脚本或者手动操作删了，Lambda执行的时候自然找不到文件。虽然你说对象没设置过期时间，但手动删除或者其他业务流程删的可能性不能排除。

4. 版本化桶的删除标记搞混了 #

如果你的桶开了版本化，删除对象时S3不会真删，而是生成一个Delete Marker标记。要是你的事件配置不小心包含了删除相关的事件（虽然默认是s3:ObjectRemoved:*），但万一配置错了，可能会误触发事件，Lambda去读的时候，实际对象已经被标记删除（或者最新版本就是Delete Marker），自然找不到。

5. 事件触发的前缀/后缀配置太宽泛 #

检查下你的S3事件配置：要是前缀设得太松（比如只设了个/），可能会触发S3内部的特殊对象事件（比如日志对象、自动生成的临时对象），这些对象可能很快就被清理了，Lambda执行时已经没了。

对应的解决办法： #

• 对付最终一致性：在Lambda代码里加重试逻辑，比如用boto3的waiter等对象存在，或者捕获NoSuchKey异常后重试个2-3次再报错。
• 对付分片上传问题：修改S3事件配置，只监听s3:ObjectCreated:Put和s3:ObjectCreated:CompleteMultipartUpload这两个事件；同时给桶开Abort Incomplete Multipart Upload规则，自动清理超时未完成的分片。
• 对付对象被删：查CloudTrail日志，看看这个对象的操作记录，确认有没有删除操作；要是业务流程导致的，可以调整Lambda的执行时机，或者给对象加个短暂的保护期。
• 对付版本化问题：检查事件配置有没有误加删除相关的事件；如果要处理版本化对象，Lambda代码里要判断当前版本是不是Delete Marker，别做无效读取。
• 对付宽泛的事件配置：收紧前缀/后缀，只监听你需要的对象路径；同时看看有没有其他服务在桶里生成临时对象，调整触发规则排除这些路径。

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