2

TL;DR - should a simple cache cluster for session storage (using memcache or redis) live on the app's servers (i.e. along with nginx and php) or on its own separate ec2 instance (like elasticache or a customized ec2 instance)?

I'm in the process of using Amazon OpsWorks to set up my web app's infrastructure. I am leaning toward implementing the session cache through memcache instances installed on the app layer itself rather than as its own ec2 instance. For instance:

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

vs.

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

What are the pros and cons here? To me the later solution seems unnecessary, though I can see how a high-traffic website with a really large session cache might need this.

Is there a reason I may not want to run redis or elasticache alongside my nginx/php app server stack? Does it make auto-scaling or monitoring performance more difficult to do perhaps?

4

2 回答 2

2

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

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

尽管在您的情况下这些可能不是问题，但通常我会尽可能避免使用它们，因为从长远来看它们往往会使问题复杂化。

于 2014-04-06T07:25:44.963 回答
1

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

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

一旦您拥有足够的应用服务器，您的缓存集群成本就会降低每台服务器的成本。

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

例如，如果您想在用户群中添加另一个应用服务器，那么添加服务器会更快，因为您在此服务器上安装的软件组件更少，并且该服务器已经可以为以前的用户提供服务他们的会话集中存储。如果您想删除一个应用服务器（或者当您丢失一个应用服务器时），由该服务器提供服务的用户可以轻松迁移到其他服务器，因为他们的会话/状态存储在缓存集群中。

于 2014-04-06T08:12:52.783 回答