1

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

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

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

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

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

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

如果在这方面有更多经验的人有一些见识，我将不胜感激。谢谢。

4

1 回答 1

4

我有一个不同的设计建议，可以解决你的问题。

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

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

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

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

于 2012-02-29T02:09:05.610 回答