流量激增

Question

我在亚马逊上有一个基本的设置，我想知道在一个新网站上，哪种方法更好，在我们逐渐建立一个合理水平的真正的会员流量之前，我们预计偶尔会有流量激增(来自科技媒体)。

我目前正在考虑两个首发选项：

1)我是否有1个节点app (微ec2)指向redis服务器和mongod (EC2服务器)(挂载一个组合的10G EBS)。

或

2)我是否有1个节点app (微ec2)在本地运行redis-server和mongod (但有2个10G EBS挂载，1个用于redis，1个用于mongo)。

如果流量变得疯狂(技术新闻等)，哪一个是最容易/最快的扩展来处理流量的峰值。我预计mongo和redis btw的读写是相等的，而且我没有缓存(除了cloudfront提供的资源，比如图像和一些css)。

Answer 1

我不能和Redis说话，但是对于MongoDB，你需要确保你运行的实例有足够的内存来保存你的“工作集”数据。“工作集”大致是指您的应用程序频繁访问的完整数据集--例如Twitter -- Twitter数据的工作集是所有用户的最新状态更新集，因为这是网页上显示的内容以及Twitter通过其API提供的内容。对于您的应用程序，工作集的定义可能有所不同。

Mongo使用内存映射文件进行数据访问，这意味着当有足够的内存来保存您频繁访问的数据时，它的性能会很好，而如果没有内存，它的性能就会下降。如果您希望您的数据集超过2.5 of，您还需要确保您是在64位实例上--在32位实例上，Mongo的数据限制在2.5 of左右，这是因为此类平台上可用的内存地址空间有限。有关EC2上的MongoDB的更多信息，请参阅维基上的the Mongo docs on EC2 deployment。

我也告诫不要在您的生产环境中使用EC2微实例。Micros的本质是它们具有“突发性”但CPU资源非常有限。如果由于技术压力而导致流量激增，您的应用程序很可能会被EC2限制在非常低的可用CPU数量上，这将导致性能下降。您可以通过负载均衡和许多微型实例在一定程度上缓解这一问题，但对于Mongo/Redis和您的应用服务器，简单地使用大型实例可能会更具成本效益，并且复杂度更低。

Answer 2

你可能想看看这个问题，因为IMO，答案也适用于你的情况：

Benefits of deploying multiple instances for serving/data/cache

我永远不会把mongod和redis-server放在一个盒子里。由于MongoDB使用的是内存映射文件，因此需要进行交换，如果数据无法放入内存，则会生成交换活动。Redis不使用与交换兼容的数据结构(就像MongoDB对btrees所做的那样)，如果它的内存被换出，它将变得不响应。目前，还没有简单的方法将Redis锁定在内存中。

所以我会把Redis和应用服务器放在同一个盒子里，把MongoDB单独放在自己的盒子里。根据您希望存储在Redis中的数据的大小，我会选择一个大的或小的EC2实例。Redis在32位下运行良好，但内存有限。对于MongoDB来说，64位的方框几乎是强制性的。在任何情况下，我都会避免像瘟疫这样的微型实例。