For the way we use memcache, key redundancy doesn't makes sense.  The 
overhead in keeping cache information on multiple servers on every 
request is not worth the gains we might get in the (rare) event a 
memcache server is removed from the pool.  Since our memcache data is 
not entirely based on underlying DB/SQL data, B thrashing issues are 
reduced.

Changes have been made in CVS for this ticket:

http://cvs.horde.org/diff.php/framework/Memcache/lib/Horde/Memcache.php?r1=1.1.2.3&r2=1.1.2.4&ty=u

Changes have been made in CVS for this ticket:

http://cvs.horde.org/diff.php/framework/Memcache/lib/Horde/Memcache.php?r1=1.3&r2=1.4&ty=u

Version 3.0 also added key redundancy.

To clarify, this is internally done by the PECL memcache driver.  As 
of memcache 2.2.0, a new PHP ini setting was added:

"memcache.hash_strategy" = {standard, consistent}

However, 'consistent' did not become the default until 3.0.0.  So I 
guess it may be useful to set this automatically if using memcache 
2.2+.  No need to make it a config option however.

Memcache already has internal consistent hashing.  When adding 
server(s) to the pool, a certain percentage of keys from the existing 
servers are moved to the new server.  When removing server(s), the 
lost keys are redistributed to the remaining servers.

I don't know enough about how pecl/memcache handles multiple memcache 
servers to know if this is redundant, but if it's not already using 
consistent hashing, we should have at least an option to manage the 
array of memcache servers ourselves, and do that to spread keys 
around. In addition, we could use this same code to implement 
multiple-write, where we write data to 2 memcache servers instead of 
one, to decrease thrashing or cache misses if a server drops out.



A good explanation:

http://www.spiteful.com/2008/03/17/programmers-toolbox-part-3-consistent-hashing/



A potential implementation (I'll be adding one to the Horde_Support 
package hopefully within a few days as well):

http://code.google.com/p/flexihash/