1

So I am working on a web app - that has to be built for scalability. It stores frequent MySQL querys into the cache. I have pretty much everything built and ready to go - but I am concerned on best practices on handling where to cache the data. I've talked to a few people and one of them suggested to split each key/value across all the memcache nodes.

Meaning if i store the example: 'somekey','this is the value'

it will be split across lets say 3 memcache servers.

Is that a better way? or is memcache more built on a 1 to 1 relationship?. For example.

store value on server A till it faults out - go to server B and store there.

that is my current understanding from the research I have done and past experience working with memcache.

Could someone please point me in the right direction in this and let me know which way is best or if I completely have this mixxed up.

Thanks

1 Answers1

2

Nearly all of the "distributed" part of memcached is handled on the client side.

If you have multiple memcached servers defined in your config (I see the php tag on your post, so I'm guessing you're using pecl/memcache, but I think the syntax is similar for pecl/memcached)

<?php 
$mc = new Memcache() 
$mc->addServer('node1', 11211); 
$mc->addServer('node2', 11211); 
$mc->addServer('node3', 11211); 
?>

the client will determine which server to put the data in using a hash of the key. There's an option of the addServer method (retry_interval = -1) where if a memcached server goes down, your PHP will not continue to try it.

There is some information about how you can do "replication" in Memcache, but from my experience, it's not really worth the effort or the "wasted" memory (you'd have to store all caches on all servers, where if you just use the built-in distribution mechanism, it'll just have to be stored on one. Obviously, if one of your servers die, you're going to get cache misses until that data is stored on another server, but you shouldn't be using Memcache as a persistent store, anyway). The Memcache client protocol is pretty smart. ;)

Original link to https://blogs.oracle.com/trond/entry/replicate_your_keys_to_multiple removed as it no longer exists.

user9517
  • 114,104
  • 20
  • 206
  • 289
bhamby
  • 243
  • 1
  • 10