我在亚马逊上设置了一个裸骨架，并且想知道哪个是更好的方法从一个新网站走出来的，我们预计偶尔会有高峰流量（来自科技媒体）建立“真实”的会员流量到合理的水平。trafic中的尖峰
我目前正在玩弄两个启动选项：
1）我有1级节点的应用程序（微EC2）指向的Redis服务器和mongod的（EC2服务器）（其中安装有一个结合10G EBS）。
或者
2）是否必须1级节点的应用程序（微EC2）运行redis的服务器和本地的mongod（但用2- 10G EBS架，1 redis的，1个用于蒙戈）。
如果流量疯狂（科技出版社等），这是最容易/最快的规模来处理交通高峰。我预计mongo和redis btw会有相同的读取写入，并且我没有缓存（除了像cloudfront资产提供的图像和一些css之外）
我无法与Redis交谈，但对于MongoDB，您需要请确保您在具有足够内存的实例上运行，以将您的“工作集”数据保存在内存中。 “工作集”大致意味着应用程序频繁访问的全部数据集 - 例如，考虑Twitter - Twitter工作集数据是所有用户中最新的一组状态更新，因为这是在网页上显示，以及Twitter通过其API提供的内容。对于您的应用程序，工作集的定义可能有所不同。
Mongo使用内存映射文件进行数据访问，这意味着当有足够的内存来存储您经常访问的数据时，它的性能会很好，并且在没有足够的内存时可能会降级。如果您希望您的数据集增长超过2.5 GB，那么您还需要确保您使用的是64位实例 - 在32位实例中，由于有限的数据，Mongo仅限于大约2.5 GB的数据内存地址空间在这种平台上可用。有关EC2上MongoDB的更多信息，请参阅Wiki上的the Mongo docs on EC2 deployment。
我也谨慎反对在生产环境中使用EC2 Micro实例。 Micros的本质是它们具有“突发性”但CPU资源非常有限。如果由于技术出版物而导致流量猛增，那么很可能您的应用程序将被EC2限制为可用CPU数量极低，从而导致性能下降。您可以在一定程度上通过负载均衡和许多Micro实例来缓解这种情况，但对于Mongo/Redis和您的应用程序服务器，只需使用Large实例可能会更具成本效益并且不那么复杂。
你可能想看看这个问题，因为IMO，得到的答案也适用于您的情况：
Benefits of deploying multiple instances for serving/data/cache
我绝不会放的mongod和Redis的服务器在同一个盒子。由于使用内存映射文件，MongoDB意味着交换，并且如果数据不适合内存，将生成交换活动。 Redis不使用与交换兼容的数据结构（如MongoDB与btrees一样），并且如果内存被换出，它将变为无响应。目前，在内存中锁定Redis并不容易。
所以我会把Redis和应用服务器放在同一个盒子里，并且在它自己的盒子上隔离MongoDB。 根据您要在Redis中存储的数据大小，我会选择一个大的或小的EC2实例。 Redis在32位中运行良好，但内存有限。对于MongoDB，一个64位的框几乎是强制性的。无论如何，我会避免像鼠疫这样的微观事件。