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). 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. 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. I think the general idea is a simple way to make memcached more highly available. Brian Beuning -----Original Message----- From: Robert Szefler To: Jeremy Dunck Cc: Brian Beuning; [email protected] Sent: 10/25/2007 10:25 AM Subject: Re: python-memcached server selection code (long) Jeremy Dunck napisal(a): > On 10/25/07, Robert Szefler <[EMAIL PROTECTED]> wrote: > >> Brian Beuning napisal(a): >> > ... > >>> With any hashing algorithm, it is always possible your >>> application uses keys that cause the hash to be unfair. >>> >>> >> This is not a matter of being fair. In fact, the algorithm is fair and, >> from a certain point of view, it is too fair. A solution to my problem >> would be to guarantee that potentially every server gets tried in a >> round and at the same time the query is random and fair in a sense. >> Which brings us to the random permutation solution I proposed. >> >> > > Perhaps interesting to you: > http://lists.danga.com/pipermail/memcached/2007-August/005099.html > From what I read here: http://www.last.fm/user/RJ/journal/2007/04/10/392555/ Interesting, yes. Related to the problem I exposed, marginally. Solving it - definitely not.
