【发布时间】：2017-02-22 19:35:10
【问题描述】：
如标题所述，如果我将事件附加到 S3 存储桶以用于放置事件，并将文件流式传输到该存储桶，一旦开始上传，该事件会触发吗？这样，接收者就可以开始下载该文件的流。
或者文件上传完成后会触发事件吗？
【问题讨论】：
标签： amazon-s3 streaming amazon-sqs
【发布时间】：2017-02-22 19:35:10
【问题描述】：
你正在考虑的有两个问题：
在上传完成之前不会触发事件。
将对象写入 S3 始终是原子操作。写入要么成功完成，要么根本不发生......并且在它成功完成之前，该对象实际上并不存在于存储桶中。
如果您正在将新对象写入存储桶，则对该对象的授权请求将返回 404 错误至少直到上传成功完成。
如果您要覆盖现有对象，则对该对象的授权请求将始终返回对象的旧副本，保持不变且未损坏，至少直到覆盖完成成功。
请注意上面“至少直到”的用法。
在所有地区，除了 US-Standard (us-east-1) 新对象的上传通常在上传后立即可用。 在美国标准中，有时可能会有短暂的延迟。 以前，S3 的 us-east-1 区域（弗吉尼亚北部，之前被指定为“美国标准”区域）没有立即提供(read-after-write) 新对象的一致性，但现在可以了。
但是，有一个问题：该对象在上传之前一定没有被请求过。如果是，则一致性模型会中断。¹
Amazon S3 为所有区域的 S3 存储桶中的新对象的 PUTS 提供写后读一致性，但需要注意的是。需要注意的是，如果您在创建对象之前对键名发出 HEAD 或 GET 请求（以查找对象是否存在），Amazon S3 会为写入后读取提供最终一致性。
http://docs.aws.amazon.com/AmazonS3/latest/dev/Introduction.html#Regions
在所有区域中，覆盖现有对象也可能会遇到短暂的延迟（删除对象可能在删除后的短时间内仍可访问）。
这种潜在延迟是由于 S3 在某些操作上的最终一致性模型，如上所述。 S3 不保证所有操作都会立即可见，尽管出于实际目的，它们几乎总是如此。 S3 所做 保证的是，如果您的上传成功完成，并且来自 S3 的成功响应，那么您的对象已提交到 S3 后备存储。
以上内容适用于PUT 上传、PUT/Copy 和多部分。
由于这些原因，S3 无法在上传尚未完成时将您的文件流式传输给消费者。
要做到这一点需要不同的解决方案（尽管 S3 当然可以在流式传输完成后用作永久存储库）。
¹一致性模型中断。几乎可以肯定，这表明到达 S3 的请求会查询存储桶索引的副本，如果索引不知道对象是否存在，它会查询更权威的指数版本。如果它仍然什么也没找到，它会在本地“记住”该对象不存在，因为上游查找是一项相对昂贵的操作——因此它不会在后续请求中再次查找上游——但是一旦创建了新的对象传播到本地索引中，该对象将可用。相同的理论解释了覆盖和删除的最终一致性。
【讨论】：
-
我正在努力寻找有关新对象的 PUT 事件何时触发的任何信息。请记住，在写入完成后的一段时间内数据可能不可见，该事件是在客户端写入结束时触发，还是在数据可供读取时触发？我是否只需要重试读取直到它在那里？
-
@fiddlesticks 它基本上是在
200 OK响应发送到客户端之后立即进行的。如果在此特定路径上从未存在任何对象，并且您从未尝试在此特定路径上执行GET或HEAD，则该对象应该在触发触发器的同时可用。如果您正在覆盖对象，那么您最安全的选择是启用存储桶版本控制，然后使用事件提供的对象版本 ID，并通过其 key+version-id 故意要求新版本。您是遇到问题，还是只是想避免潜在的问题？ -
@fiddlesticks 也感谢您将我的注意力带回到这个问题上。我更新了一些旧信息，以反映当前在 S3 中记录和观察到的内容。
-
我们有一个 Kinesis 连接器，可以将记录保存到 S3，然后将它们加载到 Redshift。我正在研究使用清单文件，以便 Redshift COPY 命令知道哪些文件应该在 S3 中进行加载。我还在考虑是否通过 lambda 进行 Redshift 加载，好像一旦 S3 文件可用就会触发 lamda，那么一切都很好。但是，我已经意识到，由于写入后读取的一致性，这些都不是必需的：我们的连接器在调用 COPY 之前执行 S3 写入，因此保证 Redshift 加载过程可以看到 S3 文件。
-
如果 Redshift 加载是异步的，则使用清单文件很好，但它需要第二个 Kinesis 流来获取清单，这会使延迟加倍。这似乎是 AWS 在博客中提到的标准模式，但我认为使用 Lambda 会更简单、更快。事实证明它不需要，所以保持简单。