我需要能够在多个EC2应用程序服务器上共享用户上传的内容。 我已经将rsync，挂载的NFS和S3看作是几乎可以实时共享这些数据的潜在选项。 上传和下载的用户文件几乎总是在1-10MB之间。 一些访问了很多，有些只是一次，然后删除。
我最新的方法是严格地将EC2实例作为文件服务器启动，与应用程序服务器分开。 使用此选项，用户可以下载文件，并将其连接到应用程序服务器之一，该应用程序服务器使用有关要下载的文件的数据查询数据库。 然后提示用户下载，并将它们连接到文件服务器进行下载。
我觉得这个选项会比我的其他选项更快。 我看到唯一的缺点是我无法自动调整向上/向下文件服务器。 然而，我可以放大并在数据库中创build一个列，指出文件位于哪个文件服务器上。
这是一个好方法还是我错过了什么？ 另外，根据服务器规格和文件在1-10MB之间来确定在文件服务器上可以发生多less并发上传/下载，或者从负载testing中最好地确定什么是一种好方法？
同样在扩展方面，如果一个文件服务器上的一个特定文件变得非常受欢迎，这会是一个问题吗？ 会用CDN解决这个问题吗？
对于您而言，CDN将是更好的select，使用S3和CloudFront将会更好。 我的build议是从应用程序服务器中分散用户生成的内容，在架构中向上或向下扩展时保持服务器不稳定，这是一个很好的devise实践。
S3和CloudFront将是第一个select，但是如果你发现延迟是不可接受的，那么还有其他的。
如果单个文件服务器对您来说运行良好，那么您可以转换到像GlusterFS这样的可扩展的分布式文件服务器平台。 这使您可以将文件存储在多个EC2实例中，并将它们显示为单个安装。 您可以使用“副本2”选项为冗余创build每个文件的2个副本。 然后在不同的可用区中使用两个实例来提高可用性。 这些文件本身存储在任何EC2支持的磁盘上，包括具有预置IOPS的EBS或者甚至SSD临时（我之前已经这样做了–Gluster的冗余使得临时性的波动更less，所以您可以获得SSD的好处快速的IO为您的关键数据）。
你想要构build你的EC2，所以他们没有任何独特的数据，把它们想象成计算机。
你有几个select。
可扩展和可靠的服务来存储和检索文件。 它不能很好地作为一个文件系统，所以如果你正在做大量的读写操作，这不是一个好的解决scheme。
静态文件（css，js，图像）可以从CloudFront（可以从S3或EC2获取数据）中提供。 这大大提高了性能，所以您可以使用S3从CloudFront获取文件并提供服务。
您可以使用一组EC2作为networking附加存储。 当然，这会给你的设置增加一点复杂性，而不是最快的解决scheme。
您可以托pipe自己的memecached或使用Elasticache服务。 该解决scheme不是文件存储，但作为高性能的分布式内存对象caching系统很有用。