Consistent Hashing for Memcached

[Gary Malouf]

I see that Akka has it's own routing implementation based on a consistent hashing function.  Many of the popular Memcached clients typically uses a Ketama hash to do their version of this.  

We have a use case where we want to route messages based on the server in which their co-located data would be in Memcached.  Is the best approach here to write our own router hashing implementation that uses a Ketama hash similar to our Memcached client?  Another option it seems would be to airlift Akka's consistent hashing function for deciding where to write.

[Gary Malouf]

Looking at the reference documentation, it appears it may use the same functionality.

[atomly]

On Mon, Sep 29, 2014 at 4:17 PM, Gary Malouf <malou...@gmail.com> wrote:

Looking at the reference documentation, it appears it may use the same functionality.

I don't believe that is correct. Akka appears to use MurmurHash whereas memcached is, as you said, based off of ketama.

You can find a clean Java implementation of memcached's ketama hashing in the Spy client:

  https://github.com/dustin/java-memcached-client/blob/master/src/main/java/net/spy/memcached/KetamaNodeLocator.java#L172

Akka's, on the other hand, is here:

  https://github.com/akka/akka/blob/v2.3.6/akka-actor/src/main/scala/akka/routing/ConsistentHash.scala#L111

  https://github.com/akka/akka/blob/v2.3.6/akka-actor/src/main/scala/akka/routing/ConsistentHashing.scala#L153

As you see on the NodeLocator, you can easily pass in a new hashing algorithm instead of its default-- I imagine it wouldn't be too much work to use the same MurmurHash implementation that Akka is using.

You also need to make sure, though, that the same thing is being hashed-- the key, in memcached terms. It appears Akka has the notion of an envelope that you can use to affect a message's hashing/routing, so this should be possible.

I have also, in the past, written a custom NodeLocator for the Spy memcached client-- it allowed us to hash certain keys based on their prefix and made all user keys use the username as a prefix, so that key "foo" for user "user" would be "user:foo" but would only hash based off of the prefix, aka the username, so that all keys for any given user would be grouped on a server and would be able to be loaded with one multi-get, cutting down our latency in a very high load environment-- and it is not that difficult. If you have any questions, I may be able to help...

:: atomly ::

[ ato...@atomly.com : www.atomly.com  : http://blog.atomly.com/ ...
[ atomiq records : new york city : +1.347.692.8661 ...
[ e-mail atomly-new...@atomly.com for atomly info and updates ...

[Akka Team]

Hi Gary,

What atomly has written is correct, but there is an alternative option, custom routers: http://doc.akka.io/docs/akka/2.3.6/scala/routing.html#Custom_Router

If you use a cluster routing you are free to implement your own logic. There is a reusable ConsistentHashingRoutingLogic class: http://doc.akka.io/api/akka/2.3.6/?_ga=1.125824842.1520294582.1409309043#akka.routing.ConsistentHashingRoutingLogic

If nothing else, you can take the code of that class and create your own one switching the hashing logic to whatever you want

-Endre

--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

--

Akka Team

Typesafe - The software stack for applications that scale

Blog: letitcrash.com
Twitter: @akkateam