S3EventNotificationRecord的getEventTime()与S3对象LastModified是否可能不一致

结论 #

二者确实可能出现不一致，属于S3事件通知的正常设计表现，并非bug

两个时间的定义差异 #

• S3EventNotificationRecord.getEventTime()：返回的是AWS内部事件通知系统生成该事件记录的时间戳，而非对象写入S3完成的时间
• S3对象LastModified属性：是对象数据、元数据全部写入持久化完成、对外可访问后的最终时间戳

不一致的核心原因 #

• 事件通知的异步排队延迟：S3事件通知本身是异步触发机制，对象写入完成后，事件会先进入内部队列等待调度，当S3负载较高时，队列排队时间可能从数毫秒到数秒不等，队列处理生成事件的时间才会被记录为getEventTime()的返回值，和对象写入完成的LastModified自然会产生差值
• 多副本同步调度差异：S3写入需要完成多可用区副本持久化才会返回写入成功，部分场景下事件生成的触发节点是主副本写入完成时，而LastModified是所有副本同步完成后的最终时间，也会产生小幅度的时间差
• 同key覆盖写入的特殊场景：如果是对同一个对象key执行覆盖写入，旧对象的删除事件和新对象的写入事件可能在内部队列出现调度顺序偏差，也可能导致事件时间和实际对象LastModified不匹配

业务适配建议 #

如果你的业务逻辑强依赖时间一致性校验，不要直接使用getEventTime()作为对象写入的基准时间，建议收到事件后先调用HeadObject接口获取该对象的LastModified属性作为时间基准使用。

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