文件上传到EC2，首先要EBS卷，然后移动到S3

Question

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

了可怕的画好抱歉，但它似乎是一个更好的方式来组织我的想法和传达出来。我一直在努力研究如何创建一个最佳的去耦合轻松扩展系统，以便将文件上传到AWS上的Web应用程序。

直接上传到S3将工作，除了文件需要立即访问上传者的操作，然后一旦操纵，他们可以到S3，他们将被提供给所有实例。

我的想法是创建一个类似glusterfs的SAN，然后直接上传到服务器上。我还没有排除它，但从不同的来源，这种解决方案的可靠性可能不太理想（如果有人有更好的见解，我很乐意听到）。无论如何，我想制定一个更“开箱即用”（在AWS的情况下）的解决方案。

所以为了详细说明这个图表，我希望文件能够上传到它碰巧去的实例的本地文件系统，这是一个EBS卷。该文件的存储位置将不会提供给公众（即的/ tmp /上传/），它仍然可以通过例如，通过在PHP中的ReadFile（）操作访问，使用户可以看到并上传后立即对其进行操作。一旦用户完成操作文件，一条消息将其移至s3可以在SQS中排队。

我的问题是再一次我保存实例上的文件“本地”（这可能是任何情况下，由于负载均衡），我怎么可以记录它是（在DB）的实例，以便后续请求通过PHP读取或移动文件会发现所述文件。

如果有人在此更多的经验，有一定的见解，我将非常感激。谢谢。

Answer 1

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

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

通过这种方式，群集中的任何节点都不需要知道其他哪些节点可能拥有该文件，因为答案总是在S3中。并且通过本地删除文件，如果其他节点更新文件，则会获得新版本的文件。

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

当然也有一堆东西我不明白你的系统。为此道歉。