python-memcached server selection code (long)
BBeuning at corecard.com
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.
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
>> 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