ketama - a consistent hashing algo for memcache clients
Dustin Sallings
dustin at spy.net
Wed Apr 11 19:36:22 UTC 2007
On Apr 11, 2007, at 11:33 , Steven Grimm wrote:
> That approach won't work if servers are typically added and removed
> in batches, which is certainly the case for us -- we hardly ever
> add just one server at a time, and when we administratively remove
> servers it's often due to a network change that forces us to remove
> a bunch of them at once. On the other hand, I think I can count on
> one hand the number of times we've needed to do that, so maybe
> we're not the best test case for this particular failure mode. More
> often we replace broken servers, but it looks like Ketama will
> handle that just fine without relocating any keys as long as we put
> the replacement machine in the same position in the list as the one
> it's replacing.
The cost of telling all other nodes to delete a value after a
mutation operation to a given node should be negligible.
It might be appropriate to have that as a mode of operation when
dealing with such a configuration. It does sound like cache
consistency isn't that hard to achieve where it's important.
--
Dustin Sallings
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20070411/c54af050/attachment.htm
More information about the memcached
mailing list