Client interoperability, server selection.
dustin at spy.net
Sun Mar 9 18:23:31 UTC 2008
On Mar 9, 2008, at 6:21, Tomash Brechko wrote:
> Indeed, when we say the client implements the Ketama consistent
> hashing algorithm, we mostly mean the idea of mapping servers onto
> points on the ring, but not necessarily the same implementation as in
I ensured my client could be configured to provide the same results
as libketama by using libketama to generate a test case that must pass
before I can generate a jar.
> While developing Cache::Memcached::Fast we considered using libketama,
> but it does too many things (I/O, shared memory, synchronization),
The shared memory thing really tripped me up for a while. It's
basically a cache, but one that I was having trouble invalidating. It
might be beneficial for short-lived processes, but that's not my target.
> plus it uses MD5 hash, which I think is an overkill: there's no
> requirement for server name hash to be irreversible, plus MD5 is 16
> bytes when only 4 bytes are needed. It's not a question of
> performance of course, as server additions/deletions are rare, but
> more a matter of minimalistic approach.
As someone mentioned, ketama does use all of the md5, but I look at
md5 as an implementation detail. I implemented md5 (with the byte
reuse) to be compatible, but I wouldn't recommend it as it will be
slower than other options.
At this point, ketama is a baseline as it is the de facto standard.
More information about the memcached