规划可伸缩Web应用程序的开发

Question

我们已经创建了一个产品，可能会为驻留在我们的服务器上的数据文件生成大量的请求。目前我们有一个共享托管服务器，它运行一个PHP脚本来查询数据库并为每个用户请求生成数据文件。这个效率并不高，迄今为止还没有成为问题，但我们希望转向更加可扩展的系统，以便我们能够寻找EC2。我们主要关注的是能够在发生数据流量时处理大量流量，并为下载数据文件的用户提供低延迟。

我在这是怎么去工作还没有不知道100％，但这样的想法：

我们使用的EC2实例来承载我们的管理面板，并生成被服务的文件应用用户。当任何管理员进行影响这些数据文件（由用户下载）的更改时，我们会使用CloudFront复制到S3。这里的想法是获取数据缓存并在S3上等待，这样我们就可以保持较低的计算时间，并且可以使用CloudFront为所有请求文件的用户获得低延迟。

我仍然在学习这个系统，并想知道是否有人对这个想法有什么反馈或对这一切如何工作有所了解。我也很好奇Cassandra这样的项目的目的。我的理解是，简单地将我们的应用程序放在EC2服务器上，可以根据服务器的性质进行扩展。 Cassandra是否只是在保持低资源使用率，还是有理由使用这样的系统，即使在EC2上？

CloudFront的：http://aws.amazon.com/cloudfront/ EC2：http://aws.amazon.com/cloudfront/ 卡桑德拉：http://cassandra.apache.org/

Answer 1

Cassandra是一个非关系型数据库引擎，如果这是你需要什么，你应该先评估亚马逊的SimpleDB：非关系数据库引擎建立在S3的顶部。

如果文件只需要根据时间（每天，每小时......）更新，那么这似乎是一个合理的解决方案。但是您可以考虑在2个EC2映像前面放置一个负载均衡器，每个映像都运行一份应用程序副本。如果一个实例失败，这将使后面的扩展更容易，更安全。

你应该阅读一些其他服务：

http://aws.amazon.com/elasticloadbalancing/ - 亚马逊负载均衡解决方案。

http://aws.amazon.com/sqs/ - 用于在DA（分布式体系结构）中的系统之间传递消息。例如，如果您希望创建数据文件的系统与承载该网站的系统不同。

http://aws.amazon.com/autoscaling/ - 允许您根据流量调整在线实例的数量

确保与EC2良好的备份过程中，快照您的操作系统驱动往往并放置任何挥发性数据（如数据库文件）在EBS块。 EC2不会经常失败，但是当它不能访问硬件时，如果你有最新的快照，你可以在线启动一个新的实例。

Answer 2

取决于数据集，Cassandra还可以显着提高查询的响应时间。

有一个在NoSQL的解决方案中使用的数据结构的一个很好的说明，可以帮助你了解是否是一个合适的解决方案，以帮助：

WTF is a Super Column