目前我使用 nginx + fastcgi 缓存响应。我正在将我的应用程序迁移到 AWS。我正在设计一种水平扩展方法，但试图确定将 nginx + fastcgi 缓存放在何处最好。
我从自己的研究中找到了一些解决方案，但都存在明显的缺点。
- 使用 AWS Elastic Load Balancer 平衡 Web 应用程序集群。每个 Web 应用程序都运行自己的 nginx 和 Web 服务器堆栈。退税：每台服务器上的缓存都需要温暖的.最坏情况1/n命中率。
- 将 nginx + fastcgi 放在 AWS ELB 前面，以便集中缓存，实现最大命中率。退税：单点故障 - 如果 nginx 死机，流量将无法传递到 ELB。已添加 nginx 实例。
我将非常感激任何关于克服上述缺点的通用架构的建议。
答案1
我在 AWS 上多次设置了这个堆栈。对我来说，选项 1 一直效果很好，而且我通常会选择它，因为它最简单。我很好奇，您处理的流量有多大，而不太理想的初始缓存命中率是一个问题？我在一对 m1.small 实例上每月提供几百万次页面浏览量，它们几乎没有出现问题。
其他想法：
Nginx 可以使用 memcached 作为缓存存储。将其插入 ElasticCache 集群。这将为您提供一个非常快速、集中的数据存储，供多个实例连接以获取缓存内容。 （我从未这样做过，但看起来可行。如果您尝试的话，请发布结果。）
选项 #2 中提到的 SPoF 问题可以通过设置包含单个实例的自动缩放组来缓解。如果它死机了，它应该会在几分钟内重新上线。不过，您需要摆弄一个自动获取弹性 IP 的启动脚本。
请记住，将任何东西放在 ELB 前面都需要使用 VPC。无论如何，这通常是一种很好的做法，但它的学习难度很高。
CloudWatch 警报操作今天刚刚发布。您可以利用它做一些很酷的事情，以帮助最大限度地减少 SPoF 问题。
答案2
看起来您正在考虑与我计划实施的相同的架构。
我考虑过这两种情况和相同的方法，然后确定了这个解决方案。
我将使用第二种选择，在负载均衡器前面设置缓存解决方案。我将通过添加一个具有备用节点并使用类似 HAProxy 的东西来处理单点故障问题，以持续检查机器的运行状况。如果第一台缓存机器发生故障，那么 HAProxy 将自动移动 IP 并将流量移动到另一台缓存备用机器，这样就可以处理单点故障。
此外，在我的场景中，我将使用类似 Varnish 的东西，而不是 Nginx+php，如果您的应用程序不依赖于 Nginx，我也会建议您这样做。Varnish 将拥有自己的内置负载均衡器，因此您也将跳过 AWS 负载均衡器。
希望这将帮助您构建强大且可扩展的基础设施。