python-memcached server selection code (long)

[Brian Beuning]

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 lists.danga.com
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 sensisoft.com> 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.