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 :)
