以圖為例
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軟件本身是有內存消耗的（相比可以忽略），但這點還是注意一下。