Better server selection client code?
Andrew Harbick
aharbick at aharbick.com
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)
Andy
More information about the memcached
mailing list