python-memcached server selection code (long)

Brian Beuning BBeuning at
Thu Oct 25 15:02:26 UTC 2007

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; memcached at
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 <robert.szefler at> 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
>> from a certain point of view, it is too fair. A solution to my
>> 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:

 From what I read here:

Interesting, yes. Related to the problem I exposed, marginally. Solving 
it - definitely not.

More information about the memcached mailing list