我的缓存守护进程应该在哪里生存？

 

TL; DR--应该在应用的服务器上（即与nginx和php一起）还是在其自己单独的ec2实例（如elasticache或定制的ec2实例）上存在一个用于会话存储的简单缓存集群（使用memcache或redis）？

我正在使用Amazon OpsWorks来设置我的Web应用程序的基础结构。 我倾向于通过安装在应用层本身上的memcache实例来实现会话缓存，而不是将其作为自己的ec2实例。 例如： 

                 [ Load Balancer ]
                /        |        
[ App Layer 1 ] – [ App Layer 2 ] – [ App Layer 3 ]  * /w memcache or redis

与 

                 [ Load Balancer ]
               /         |         
[ App Layer 1 ]   [ App Layer 2 ]   [ App Layer 3 ]
                        |         /
                [ Cache Server(s) ]   * ElastiCache or custom ec2 /w memcache or redis

这里有什么优点和缺点？ 对我来说，后面的解决方案看起来没有必要，但我可以看到具有非常大的会话缓存的高流量网站可能需要这样做。

是否有我不想在我的nginx / php应用程序服务器堆栈旁边运行redis或elasticache的原因？ 它是否会使自动缩放或监视性能更难以做到？

在应用程序服务器上放置缓存的主要原因是成本问题。 这与您的数据库不在您的Web或应用程序服务器上的相同服务器上的想法是一样的。

如果你有一个小规模的应用程序，你可能会挤压你所有的资源在同一台机器上，但是你有能力从任何类型的故障中恢复（和“一切都失败”），你将丢失数据或者它会占用你的一部分为某些用户提供服务。

一旦拥有足够的应用程序服务器，每个服务器的缓存集群成本就会更小。

从体系结构的角度来看，当规模和高可用性很重要时，您应该拥有比少数几个更复杂的组件更小的组件。

例如，如果您希望将另一台应用程序服务器添加到您的机群，因为您拥有更多用户，添加服务器的速度会更快，因为您在此服务器上安装的软件组件较少，并且服务器已可以将以前的用户作为他们的会话集中存储。 如果要删除应用程序服务器（或丢失应用程序服务器），则由该服务器提供服务的用户可以轻松迁移到其他服务器，因为其会话/状态存储在缓存集群中。

第一种解决方案的两个主要缺点是：

  • 你将被迫进入会话粘性。
  • 您将应用程序和缓存的缩放事件结合在一起。

    • 虽然在你的情况下这些可能不是问题，但通常我会尽可能避免它们，因为它们往往会使问题长期复杂化。

    链接地址: http://www.djcxy.com/p/54101.html

    上一篇: Where should my caching daemon live?

    下一篇: How to use enyim memcached client with amazon elasticache in c#