I recently evaluated whether to use memcached-session-manager  for one of our webapps. Although memcached-session-manager bases on spymemcached  for communicating with memcached, I was surprised that it uses a significant different algorithm for selecting a memcached instance (out of a pool of given memcached instances) than the native implementation of spymemcached.
Spymemcached selects the instance by calculating a hash of the element’s key and using that hash to determine the instance. Simplified this could be done by compute:
server = serverlist[hash(key)%serverlist.length]
To distribute the elements uniformly on all nodes often Consistent Hashing , e.g. KETAMA, is used as hash function. See  for details.
In contrast to that, memcached-session-manager doesn’t use hashing at all – it simply “selects the memcached node randomly”  (excluding failover nodes). After that the node id is encoded in the session id like 72d9ffcb00d836b3248d8bd95ce2e641-n1.tomcat1 (“n1”). All further accesses are selected by this value.
-  https://code.google.com/p/memcached-session-manager
-  https://code.google.com/p/spymemcached
-  https://en.wikipedia.org/wiki/Consistent_hashing
-  http://www.lastfm.de/user/RJ/journal/2007/04/10/rz_libketama_-_a_consistent_hashing_algo_for_memcache_clients
-  https://code.google.com/p/memcached-session-manager/wiki/FAQ