我在一个亚马逊实例中有一个基于php的应用程序，用于上传和转码音频文件。该应用程序首先上传文件，然后对其进行转码，最后将其放入一个s3存储桶中。目前，应用程序通过监视临时文件夹中的文件大小，根据重复的ajax请求显示文件上载和转码的进度。
我一直想知道明天的用户是否会急于使用我的服务，我需要在AWS中以任何可能的方式扩展我的服务。
答：我的上传和转码技术会怎样？
B：如果我添加更多实例，是否意味着我在不同的物理位置的不同临时转换文件夹中有不同的文件？
C：如果我想通过ajax从http://www.example.com/filesize获取文件大小直到完成过程，我需要拥有每个ec2实例的真实地址（我的意思是ip，dns）或所有实例文件夹（或文件夹）？
D：当我们扩展临时文件夹会发生什么情况时，除了灯堆之外的所有实例都找到主实例的一个根文件夹是否正确？
我有一些关于其他主机技术扩展的基本信息，但在亚马逊中，这些问题都在我的脑海中。
感谢您的建议。
答案 0 :(得分：0)
如果不了解更多关于应用程序架构的内容，很难回答您的问题，但鉴于您使用的是临时文件，这里有一个猜测：
您的扩展能力完全取决于您的架构，当然还有足够深的钱包来支付。
是。如果您在单个计算机上生成临时文件，它们将不会按照您当前描述的方式存储在共享位置。
是。您需要一些方法来了解文件的存储位置。您可以通过ELB粘性策略解决这个问题（即通过ELB的流量被路由到相同的实例），但它们有点痛苦，并不一定能解决您的问题。
不太确定这里的问题是什么。
听起来好像您处于应用的早期阶段，请先查看this tutorial和this tutorial。第一个描述了基于Amazon SQS构建的缩略图服务，第二个是视频处理服务。它们将帮助您设计最佳的AWS实践，并帮助您避免现在担心的许多问题。
答案 1 :(得分：0)
解决扩展和会话粘性的一种方法是使转码更新具有当前进度的数据库。任何返回的用户都会检查数据库以查看其上载的进度。由于进度存储在一个地方，因此无需跟踪转码的位置。
然而，就像克里斯托弗所说的那样，我们对你的申请一无所知，我们给出的任何建议都是从外面看的，我们不知道什么是最简单的事情。你要做。这似乎是一个非常简单的解决方案，但我可能会遗漏一些东西，因为我对您的应用程序或架构一无所知。