以图为例
Cache A、Cache B，Cache C为三台Memcached服务器
根据三台Memcached的IP和端口，计算出他们的Hash值，然后分布在整个圆环上
每两台Memcached服务器的Hash值之间为一个区间
Key1、Key2、Key3、Key4
为要存储在Memcached里的4个Key
根据4个Key计算出他们的Hash值，同样也落在这个圆环上
在这个环形空间中，如果沿着顺时针方向从对象的 key 值出发，直到遇见一个 cache ，那么就将该对象存储在这个 cache 上，因为对象和 cache 的 hash 值是固定的，因此这个 cache 必然是唯一和确定的。
根据上面的方法，对象 key1 将被存储到 cache A 上； key2 和 key3 对应到 cache C ； key4 对应到 cache B;
同一个key不是三台服务器上面都有映射， 只会映射到其中一台服务器上面
集群中其中一个Memcached节点宕机，会导致存在着上面的Key全部失效而重新对这些key进行hash
对其他活着的Memcached节点上的key没有影响
如果是集群
Set和Get时触发操作的是否为同一个配置
如果是多个应用服务器触发Set、Get操作，每一个的Memcached节点配置顺序是否相同
可以通过telnet的方式，去Memcached节点上Get一下响应的Key，看是否真的过期
你分析一下你的slab构成，看看每个slab分配了多少page页，加起来是不是跟总分配内存一样，如果是一样的表示你的内存已经分配完了，每个slab只能使用已分配的大小，不能再增涨。再分析一下存这个value的slab的大小，如果比较小，且hits量很大，就会出现你这样的情况，刚存没多久的数据没到过期就会被挤掉。
失效就几种可能：
1，cache满了，刚插进去就被lru剔出来
2，失效时间设置不对，导致数据一插进去就失效（不能超过30天）
使用了64的操作系统，能分配2GB以上的内存。32位操作系统中，每个进程最多只能使用2GB内存。可以启动多个分配2GB以下内存的进程，但这样一台服务器上的TCP连接数就会成倍增加，管理上也变得复杂，所以尽量统一使用了64位操作系统。
另外，最好分配内存为3GB，是因为内存分配量超过这个值，就有可能导致内存交换(swap)，memcached的内存存储“slab”， memcached启动时指定的内存分配量是memcached用于保存数据的量，没有包括“slab”本身占用的内存、以及为了保存数据而设置的管理空间。因此，memcached进程的实际内存分配量要比指定的容量要大。
如果在memcached中的数据大部分都比较小。这样，进程的大小要比指定的容量大很多。因此，改变内存分配量进行验证，确认了3GB的大小不会引发swap。
64位操作系统不受限制（小于你的物理内存大小即可），不过得注意Memcache软件本身是有内存消耗的（相比可以忽略），但这点还是注意一下。