锁定 s3 对象的最佳实践？答案

【问题标题】：Locking an s3 object best practice?锁定 s3 对象的最佳实践？
【发布时间】：2016-01-25 16:18:13
【问题描述】：

我有一个 S3 存储桶，其中包含多个 EC2 实例可以从中提取的多个 S3 对象（水平扩展时）。每个 EC2 将一次拉出一个对象，对其进行处理，然后将其移动到另一个存储桶。

目前，为了确保同一个对象不会被多个 EC2 实例处理，我的 Java 应用程序通过添加到其 S3 对象键中的“锁定”扩展名来重命名它。问题是“重命名”实际上是在做“移动”。因此 S3 存储桶中的大文件最多可能需要几分钟才能完成其“重命名”，从而导致锁定过程无效。

有没有人有完成我想要做的事情的最佳实践？

我考虑过使用 SQS，但这种“解决方案”有其自身的一系列问题（订单无法保证，消息可能多次传递，以及多个 EC2 收到相同的消息）

我想知道设置“锁定”标题是否会是一个更快的“锁定”过程。

【问题讨论】：

我没有发布答案，因为我没有关于“锁定”S3 文件的问题的答案。但是，也许另一种选择是根本不使用并发，并让进程生成自己的文件，所有这些文件都在以后连接起来。我认为您在连接中损失的时间来自于避免并发瓶颈所节省的时间。如果这些进程将永远运行，那么可能需要一个类似于在达到文件大小后归档的系统。

标签： amazon-web-services amazon-s3 amazon-ec2

【解决方案1】：

订单不保证，消息可能多次传递，并且不止一个 EC2 收到相同的消息

实际上多次收到相同消息的几率很低。这只是“可能”，但不太可能。如果在个别情况下，如果您碰巧不止一次地处理一个文件，这基本上只是一个烦恼，那么 SQS 似乎是一个完全合理的选择。

否则，您将需要外部机制。

在对象上设置“锁定”标头有其自身的问题 - 当您使用其自身的副本覆盖对象时（当您更改元数据时会发生这种情况 - 创建对象的新副本，使用相同的键），那么您将受到最终一致性的吊索和箭头的影响。

问：Amazon S3 采用什么数据一致性模型？

所有区域中的 Amazon S3 存储桶为新对象的 PUTS 提供写后读一致性，并为覆盖 PUTS 和 DELETES 提供最终一致性。

https://aws.amazon.com/s3/faqs/

更新元数据是“覆盖PUT”。您的新标头可能不会立即可见，并且如果两个或更多工作人员设置了自己的唯一标头（例如 x-amz-meta-locked: i-12345678），则完全有可能出现以下情况（W1，W2 = 工人 #1 和 #2）：

W1: HEAD object (no lock header seen)
W2: HEAD object (no lock header seen)
W1: set header
W2: set header
W1: HEAD object (sees its own lock header)
W2: HEAD object (sees its own lock header)

相同或相似的故障可能发生在几种不同的时序排列下。

在这样的最终一致性环境中无法有效地锁定对象。

【讨论】：

TLDR：你需要一个数据库来做数据库的事情。
Amazon Elastic File 会更好地工作吗？或者，它只是一个带有 S3 后端的不同前端（或至少相同的限制）？
弹性文件系统应该工作得更好。它不是 S3 的前端，它是立即一致的，并且它支持实际的 NFS 锁定......但它目前仍处于预览阶段，仅在 us-west-2（俄勒冈州）可用。

【解决方案2】：

对象标签可以在这里提供帮助，因为更改标签不会创建新副本。标签是一种与对象关联的键/值对。即您需要使用对象级标记。

【讨论】：

感谢 Tejas，这是一个绝妙的解决方案！

【解决方案3】：

您是否考虑过为您的用例使用 FIFO 队列。 FIFO 队列不是尽力而为排序，而是维护从消息发送到队列到轮询消息的顺序。您还可以确保您的对象只处理一次，因为重复数据删除允许只处理一次。

【讨论】：

【解决方案4】：

此后，S3 一致性模型发生了变化。现在它支持新对象和对象覆盖的强写后读一致性。 https://aws.amazon.com/s3/faqs/

在成功写入新对象或覆盖现有对象后，任何后续的读取请求都会立即收到对象的最新版本。

【讨论】：