python-memcached server selection code (long)

Robert Szefler robert.szefler at sensisoft.com
Thu Oct 25 15:11:21 UTC 2007


Brian Beuning napisał(a):
> What I hear you asking for is a guaranteed fast responce time
> for frequent queries even if a node hosting the cache is down.
>
> I am looking for this also, and here are the replies I have seen:
> 1. Spread the cache (even if it is small) out over lots of machines,
>  then the odds of a key you need being gone are low (but not zero).
>   
This is not an option, at least with the current code. It would mean 
that the problem of 1 key in a thousand not being able to be stored 
anywhere remains, just the number 1000 changes. And the solution could 
be economically unsound in some situations.
> 2. Use the consistent hashing stuff and when a machine goes down
>  remove it from the cache configuration file.  Without consistent
>  hashing removing a machine would flush the cache on all nodes.
>  With consistent hashing the impact is greatly reduced.
>   
Please, could you describe it in more detail to me? I guess I don't see 
the idea clearly from the short description Jeremy posted.
> A quick look at your patch and it seems you are put/get'ing keys
> on different nodes if the usual node for a key is down.
>   
Well, this is also the behavior of the original code so I guess this was 
intended? (Which is strange, but still, nobody's perfect).
> I think the general idea is a simple way to make memcached
> more highly available.
>   
Oh well, if only it was that easy :)


More information about the memcached mailing list