我需要能够在多个 EC2 应用程序服务器之间共享用户上传的内容。我曾考虑过 rsync、mounted NFS 和 S3 作为能够几乎实时共享这些数据的潜在选项。上传和下载的用户文件几乎总是在 1-10MB 之间。有些文件访问量很大，有些文件只访问一次，然后就被删除了。
我最新的方法是将 EC2 实例严格地作为文件服务器启动，与应用程序服务器分开。使用此选项，对于要下载文件的用户，他们会连接到其中一个应用程序服务器，该服务器会使用他们想要下载的文件的数据查询数据库。然后提示用户下载，从而将他们连接到文件服务器进行下载。
我觉得这个选项会比其他选项更快。我看到的唯一缺点是我无法自动扩展/缩小文件服务器。不过我可以扩展并在数据库中创建一个列，说明文件位于哪个文件服务器上。
这是一个好方法还是我遗漏了什么？另外，根据服务器规格以及文件大小在 1-10MB 之间，有什么好方法可以确定文件服务器上可以进行多少次并发上传/下载，或者最好通过负载测试来确定？
另外，在扩展方面，如果仅位于 1 个文件服务器上的 1 个特定文件变得非常流行，这会是个问题吗？使用 CDN 可以解决这个问题吗？
答案1
CDN 对你来说会是更好的选择，使用 S3 和 CloudFront 会更好。我的建议是将用户生成的内容从应用程序服务器中分散出来，在你的架构内扩展或缩小时保持服务器的易变性是一种很好的设计实践。
答案2
S3 和 CloudFront 将是首选，但如果您发现延迟不可接受，那么还有其他选择。
如果单个文件服务器运行良好，您可以转换到可扩展的分布式文件服务器平台，例如集群文件系统。这允许您跨多个 EC2 实例存储文件，并使它们显示为单个挂载。您可以使用“副本 2”选项为每个文件创建 2 个副本以实现冗余。然后使用不同可用区域中的两个实例来提高可用性。文件本身存储在任何 EC2 支持的磁盘上，其中包括具有预配置 IOPS 的 EBS 或甚至是 SSD 临时磁盘（我以前这样做过 - Gluster 的冗余性使临时磁盘的波动性不再那么令人担忧，因此您可以为关键数据获得 SSD 快速 IO 的好处）。
答案3
您希望设计您的 EC2，使得它们上没有任何唯一数据，将它们简单地视为计算机器。
您有几种选择。
S3
可扩展且可靠的文件存储和检索服务。它作为文件系统效果不佳，因此如果您进行大量读写操作，它不是一个很好的解决方案。
CloudFront（CDN）
静态文件（css、js、图像）可由 CloudFront 提供（可从 S3 或 EC2 获取数据）。这大大提高了性能，因此您可以使用 S3 获取文件并从 CloudFront 提供它们。
集群文件系统
您可以使用 EC2 集群作为网络附加存储。当然，这会增加设置的一些复杂性，并且不是最快的解决方案。
Elasticache/Memecached
您可以托管自己的 memecached 或使用 Elasticache 服务。此解决方案不是文件存储，但可用作高性能分布式内存对象缓存系统。