Spreading key/value pairs across multiple memcached servers
brad at danga.com
Wed Dec 1 09:45:20 PST 2004
Yes, but that's an issue I have a solution for and have mostly
implemented, but it's been low priorirty. In practice we haven't had to
resize our memcached farm often enough to upgrade its priority.
On Wed, 1 Dec 2004, Chris Hartjes wrote:
> Okay, one last question before the sales pitch (which is looking good anyway):
> Since the client accepts a list of what servers to talk to, I'm
> assuming that when you put a new memcached server up, you have to
> modify your code to pass the new server to your client, right?
> On Wed, 1 Dec 2004 08:56:47 -0800 (PST), Brad Fitzpatrick
> <brad at danga.com> wrote:
> > On Wed, 1 Dec 2004, Chris Hartjes wrote:
> > > Pardon my ignorance of memcached as I post the following scenario:
> > >
> > > 1) I create an instance of a memecached client (PHP version)
> > > 2) I'm using memcached to cache MySQL result sets, using the query
> > > itself as the key
> > > 3) I ask memcached "hey, retrieve this key from memcache for me"
> > >
> > > Now, if I have two servers, what server will it talk to in order to
> > > find out where the key is?
> > The right one.
> > The memcached client library knows how to find the right server
> > immediately, without searching them all. It uses a hash function to
> > calculate the hash of the key, mod the number of memcached servers.
> > Read:
> > http://en.wikipedia.org/wiki/Hash_function
> > > Will it always talk to the first server in
> > > the list? I understand that the various servers are aware of what
> > > server a particular key is on. I also understand it will only take
> > > one request to find out where a key is. But again, will that request
> > > for the location of the key always go to one server?
> > It will go to no server. It doesn't need to ask anybody where the key
> > is at. It just knows.
> > - Brad
> Chris Hartjes
> "I know monkeys, and monkeys are good people!"
More information about the memcached