Better server selection client code?

Andrew Harbick aharbick at
Fri Oct 20 14:26:22 UTC 2006

> Right. Here it is not balanced, but when you add the fourth, the
> servers will be at 0, 0.25, 0.5, 0.75

Sure.  But when the total number of servers isn't a power of 2 then 
you're unbalanced.

> This exactly was my concern - load is not balanced with this
> consistent hashing, unless I decide to keep multiple copies of each
> entry - which ads a new dimension to choice of positions for a new
> server to be added!

My solution does balance load (assuming your key hash is evenly 
distributed).  Servers are placed around the unit circle at even intervals.

> moreover - we *cannot* think of a solution that moves a set of keys,
> because theres no way of iterating on all keys!

Keys aren't *moved*.  Instead they are abandoned in their old server and 
eventually evicted.  They get re-fetched from the database and stored in 
their new server.  This is exactly how the current client works but the 
current mechanism relocates all keys to a new server when a server is 
added.  My proposal only moves a percentage of the keys (i.e. 35% when 
adding a 5th server to a fleet of 4)


More information about the memcached mailing list