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