Memcached虽然是“分布式”缓存服务器程序，但是该程序并没有“分布式”功能；不同的Memcached服务进程之间是不进行相互通信的。而Memcached的“分布式”则是基于开发者在客户端自己通过自己写的算法来撸的。
Memcache的分布式算法有很多，没啥绝对标准可言。但是绝大多数情况要考虑一下是基于键（key）的哪种特殊属性，请尽量要选择那种分散性较高的标准、而不是选择一个偏颇而极容易造成分布不均的属性。
根据余数计算的分散性，不仅简洁，而且分散性相对较高。不过对哪种属性进行求余数运算，也要注意。键（key）字符串的适合选择的属性不只一种；比如可以将字符串中所有的字符的ASCII码值累加起来，再进行求余数计算。以上图为例，有3个大小相同的Memcached缓存服务；那则是用3来求余数，若余数为0，则对应的是Node1缓存；若余数为1，则对应的是Node2缓存；若余数为2，则对应的是Node3缓存。比如若键（key）为字符串“zhuanfou”，该字符串有8个字符，各字符的ASCII码值依次为122、104、117、97、110、102、111、117，累加起来得到的和值为880，880整除3得到的余数为1，则“zhuanfou”作为键名的数据对应的Node2缓存服务。
所有客户端程序都可以基于某种统一固定的算法来选择相应的缓存服务；存入数据如此，获取数据亦如此。
不过余数算法也有一点点不足之处，那就是添加服务器后（热添加），键的分布会有极大的变化，从而在更新后的某段时间内对命中率造成一定影响；使用Consistent Hashing的算法可以缓解这种影响。但是！Memcached只是缓存，对缓存的依赖性不应如此之甚，所以没必要考虑这个细节问题。另外，现在云计算平台提供的云内存服务，基本上都是可以动态提升内存空间大小的，分布式算法暂时都可以不用考虑。用钱砸是王道。如果一定要基于算法使用Memcached分布式，而且对动态更新缓存服务追求极致的话，那就不要单纯地使用某种算法，而应将键名、数据大小、过期时间等信息存入某个单独可靠的缓存中，依托此缓存服务，对其他所有的缓存服务进行精细化管理；从而将分散性达到最高，且动态更新缓存服务，对命中率造成的影响降到最低，甚至可以做到完全没有影响。用于管理器的那个单独的缓存，最好可以具有数据持久性，比如Redis这种内存型数据库就挺适合。
