Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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

share|improve this question

2 Answers 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.

share|improve this answer
    
Since I can't post more than one link, pecl/memcache: pecl.php.net/package/memcache –  bhamby Dec 7 '10 at 17:29
    
pecl/memcached: pecl.php.net/package/memcached –  bhamby Dec 7 '10 at 17:29

memcached is a caching mechanism, it is not intended for permanent storage of data, always assume that memcached should help you speed up things, not do storage of metadata, there's better suited options for that (have a look at redis database for example).

It's also very important in memcached which hash key you use to decide the destination server, as soon as you determine a hash key mechanism this will always map the stored value to the right server (there's several techniques for hash mechanisms. very interesting subject), by default memcached hash will map rightly to the server with a hash key method that serves most scenarios.

Also a consideration that you should have in mind is that memcached suffers from fragmentation due to the slab allocation mechanism, so it's also a good technique to change your hashing mechanism to avoid slab caused degradation.

Have a look at some different hash mechanisms here.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.