将文件上传到 ec2，首先到 ebs 卷然后移动到 s3

Question

http://farm8.staticflickr.com/7020/6702134377_cf70482470_z.jpg

好吧，抱歉画的很糟糕，但这似乎是一种更好的方式来组织我的想法并传达它们。一段时间以来，我一直在努力研究如何创建一个最佳的解耦、易于扩展的系统，用于将文件上传到 AWS 上的 Web 应用程序。

直接上传到 S3 是可行的，只是上传者需要立即访问文件以进行操作，然后一旦被操作，他们就可以转到 s3，在那里它们将被提供给所有实例。

我想用 glusterfs 之类的东西创建一个 SAN，然后直接上传到那里并从中提供服务。我没有排除它，但从不同的来源来看，这个解决方案的可靠性可能不太理想（如果有人对此有更好的了解，我很想听听）。无论如何，我想制定一个更“开箱即用”（在 AWS 环境中）的解决方案。

所以为了详细说明这个图，我希望将文件上传到它碰巧要去的实例的本地文件系统，这是一个 EBS 卷。文件的存储位置不会向公众提供（即 /tmp/uploads/ ），实例仍然可以通过 PHP 中的 readfile() 操作访问它，以便用户在上传后立即查看和操作它。用户完成对文件的操作后，一条将其移动到 s3 的消息可能会在 SQS 中排队。

我的问题是，一旦我将文件“本地”保存在实例上（由于负载均衡器可能是任何实例），我如何记录它所在的实例（在数据库中）以便后续请求通过PHP 读取或移动文件会找到所说的文件。

如果在这方面有更多经验的人有一些见解，我将非常感激。谢谢。

Answer 1

我有一个不同的设计建议，可能会解决您的问题。

为什么不总是先将文件写入 S3？然后将其复制到本地 EBS 文件系统上，无论您在哪个节点上工作（我不太确定您需要执行哪些操作，但我希望这无关紧要）。修改完文件后，只需将其写回 S3 并从本地 EBS 卷中删除即可。

通过这种方式，您的集群中的任何节点都不需要知道其他哪些节点可能拥有该文件，因为答案是它始终在 S3 中。通过在本地删除文件，如果另一个节点对其进行更新，您将获得该文件的新版本。

如果每次从 S3 复制文件的成本太高，您可能会考虑的另一件事（它太大，或者您不喜欢延迟）。您可以在负载均衡器中打开会话亲和性（AWS 将其称为粘性会话）。这可以由您自己的 cookie 或 ELB 处理。现在，来自同一浏览器的后续请求会到达同一集群节点。只需根据 S3 副本检查本地 EBS 卷上文件的修改时间，如果它是较新的，则进行替换。然后，您可以在处理文件时利用本地 EBS 文件系统。

当然，我对您的系统有很多不了解的地方。对此深表歉意。