search

slimina / spymemcached

Automatically exported from code.google.com/p/spymemcached
0 stars 0 forks source link

KetamaNodeLocator / KetamaIterator.next() should "go around the circle" instead of rehashing #117

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What version of the product are you using? On what operating system?

spymemcached 2.5rc1

Tell me more...

When one hashes a key K into the ketama consistent hash ring/circle to find
the list of servers (primary and alternatives) that should hold that K
key... one should conceptually go "clockwise" around the circle to find the
list of servers for key K.  

So, when a primary server (for key K) disappears, the next alternative
server is the next server that's clockwise in circle.

The KetamaInteraor.next() implementation in spymemcached, instead, does
something different -- it rehashes on the previous hash result point, which
has the effect of jumping to a different part of the circle rather than
using the next neighbor.

libmemcached, emoxi and erlmc memcached clients follow the behavior of
"going around the circle".

Original issue reported on code.google.com by steve....@gmail.com on 3 Feb 2010 at 11:45

GoogleCodeExporter commented 9 years ago 
The current implementation of re-hashing has the drawback that for some keys, 
you won't try all memcached hosts in the circle.  The fewer memcached hosts, 
the bigger the impact of this limitation.

Original comment by kevin.la...@gmail.com on 14 Sep 2010 at 12:54

GoogleCodeExporter commented 9 years ago

Original comment by ingen...@gmail.com on 19 Apr 2011 at 7:33

GoogleCodeExporter commented 9 years ago 
@kevin: With regard to the fewer hosts the bigger the impact, I've just 
submitted a change for this that should guarantee that even in the case of two 
hosts, you'd have less thank 1% chance of always getting a down node.  I 
believe this is the right fix.

@steve: With regard to picking the next host, I believe there are tests that 
show compatibility with libketama.  I will verify those a bit further and then 
close this issue if in fact it's correct.  Picking the "next" host is actually 
easier, but if it's more correct then it'll be a bit more work to fix.

Original comment by ingen...@gmail.com on 19 Apr 2011 at 3:03