Caching (memcache/redis) and multiple servers – best strategy

cachedeploymentload balancingmemcachedredis

We're considering best strategy for using cache (memcache or redis based) in our application (Symfony2). It will be deployed on multiple (so far 3) separate machines with load balancing and separate replicated databases + one common shared storage. There's also fourth server, used mostly for crons and sending mass mailing.
Please note that cache will be frequently not only used, but also updated due to frequent data changes.

So far we have three attempts:

  1. we place single cache on fourth machine and share it across the domain. Bad side is, when this machine fails, everything fails.

  2. we place separate caches on multiple machines, each one has it's own cache. Downside is that we have to reserve more computing power to do redundant task.

  3. one machine rebuilds the cache and then propagates it to separate machines (downside same as in 1st case).

What's the best option to handle this?

Best Answer

If I read well the published information, memcache supports data replication accross multiple servers through a daemon called repcached. I must add I never used memcache though.

I have used redis, and I know that it supports Master-Slave setups.

In both cases, you may want to install your daemon on all the machines, and have data replicated in a master-slave fashion. You would then tune the refresh delay to have a consistent replica for your setup.

Reasons include:

  • no need to setup dedicated replication mechanism, your daemon will handle the task
  • shall any of the machines fail, the setup will keep working without problems, other machines will just lose connectivity to the failed one and share the load. You would then be able to switch any of the three remaining nodes to master for the time being

Application side, you may want to connect to a single instance of your daemon for reading and writing (usually the master one), and have the slaves replicate data in a lazy fashion.

This would allow to rip off the best performance, because the cache can always access hot data directly. This setup would also mantain a decent availability (allowing X time of "missed data" due to failure, where you can configure X as you like). You may also want to load-balance the cache dns entry, so that your application instances would always find an available cache.

If you choose redis, be sure to enable both the data persistence modes (RDB and AOF).

Related Topic