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