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