Amazon s3 如果我将文件流式传输到s3，那么一旦文件完成，事件是否会触发？

正如标题所说，如果我为put事件将一个事件附加到S3存储桶，并将一个文件流式传输到该存储桶，那么一旦上传开始，事件会触发吗？这样，接收方就可以开始下载该文件的流

---

或者该事件是否会在文件上传完成后触发？

您考虑的问题有两个：

• 直到上传完成，事件才会触发

• 将对象写入S3始终是一个原子操作。写入操作要么成功完成，要么根本没有发生。。。在成功完成之前，对象实际上并不存在于bucket中

如果您正在将一个新对象写入一个bucket，对该对象的授权请求将返回404错误，至少在上传成功完成之前是这样

如果要覆盖现有对象，则对该对象的授权请求将始终返回该对象的旧副本（未更改且未损坏），至少在覆盖成功完成之前是如此

注意上面“至少到”的用法

在所有地区，除美国标准（US-east-1）外，新对象的上载通常在上载后立即可用。在美国标准中，有时可能会有短暂的延迟。以前，S3的us-east-1区域（弗吉尼亚州北部，以前被指定为“美国标准”区域）没有为新对象提供即时（先读后写）一致性，但现在它提供了

但是，有一个问题：在上传对象之前，该对象一定没有被请求过。如果是，则一致性模型将中断。ª

AmazonS3在所有区域为S3存储桶中的新对象提供了读写一致性，但有一点需要注意。需要注意的是，如果您在创建对象之前对密钥名发出HEAD或GET请求（以查找对象是否存在），AmazonS3将为写后读提供最终的一致性

在所有区域中，对现有对象的覆盖也可能会遇到短暂的延迟（删除对象后可能会在短时间内保持可访问性）

这种潜在的延迟是由于S3在某些操作上的最终一致性模型造成的，如上所述。S3不能保证所有操作都立即可见，尽管出于实际目的，它们几乎总是可见的。S3所保证的是，如果您的上传成功完成，并且S3做出了成功响应，那么您的对象将提交到S3备份存储

上述内容适用于

PUT

上载、PUT/Copy和多部分

由于这些原因，当上传尚未完成时，S3无法将您的文件流式输出给使用者

要做到这一点，需要一个不同的解决方案（尽管S3当然可以在流式处理完成后用作永久存储库）

---

---

一致性模型中断。几乎可以肯定的是，这表明到达S3的请求会参考bucket索引的副本，如果索引不知道对象是否存在，则会参考更权威的索引版本。如果仍然找不到任何东西，它会在本地“记住”对象不存在，因为上游查找是一个相对昂贵的操作——因此它不会在后续请求中再次向上游查找——但一旦新对象的创建传播到本地索引中，该对象将可用。同样的理论解释了覆盖和删除的最终一致性。

我正在努力寻找关于新对象的PUT事件触发的确切时间的任何信息。请记住，数据可能在写入完成后的一段时间内才可见，事件是在客户端写入结束时触发的，还是在数据可供读取时触发的？我是否只需要重试读取直到它到达那里？@fiddlesticks它基本上是在

200ok

响应发送到客户端之后立即执行的。如果在此特定路径上从未存在任何对象，并且您从未尝试在此特定路径上执行

GET

或

HEAD

，则该对象应在触发触发器的同时可用。如果您正在覆盖对象，那么最安全的方法是启用bucket版本控制，然后使用事件提供的对象版本ID，并通过其key+version-ID故意请求新版本。您是有问题，还是只是试图避免潜在问题？@fiddlesticks，谢谢你把我的注意力带回这个问题上来。我更新了一些旧的信息，以反映S3中当前记录和观察到的内容。我们有一个Kinesis连接器，它将记录保存到S3，然后将记录加载到红移。我正在研究使用清单文件，以便Redshift COPY命令知道哪些文件应该在S3中加载。我也在考虑是否通过lambda进行红移加载，好像一旦S3文件可用，lamda就会被触发，那么一切都好了。然而，我已经意识到，由于写后读的一致性，这两项都不是必需的：我们的连接器在调用副本之前进行S3写入，因此红移加载过程保证可以看到S3文件。如果红移加载是异步的，则使用清单文件是可以的，但它需要第二个Kinesis流来获取清单，这使延迟增加了一倍。这似乎是AWS在博客中提到的标准模式，但我认为使用Lambda会更简单、更快。事实证明它是不需要的，所以保持简单。