缓存雪崩现象
一般是由于某个节点失效，导致其它节点的缓存命中率下降，缓存中缺失的数据直接去数据库查询，短时间内造成数据库服务器崩溃。
或者是由于缓存周期性失效，比如设置每隔6个小时失效一次，那么每6个小时将会有一个请求峰值，严重的话，也会导致数据库崩溃。
重启DB后，短期内又被压垮，但缓存又会恢复一点，DB反复重启多次，直至缓存重建完毕，才能恢复稳定。
如果小网站，平时访问量不大的情况下，数据缓存的时间不同，失效时间也不同，可能不会出现此问题。而对于一些访问量较大的网站，可能memcache一开起，瞬间几万次，甚至几千万次的同时访问，短期内就会缓存完所有的，也就会导致近似同时失效，出现上述这种后果。
解决方案：
- 缓存有效期随机设置3-9小时之间的一个随机值。
- 控制缓存在闲时过期（比如夜里）。
缓存无底洞现象
Facebook的工作人员反应2010年已达到3000个memcached节点，储存数千G的缓存。
他们发现一个问题–memcached的连接效率下降了，于是增加了Memcache节点，添加之后，发现因为连接频率导致的问题，仍然存在看，并没有好转。
以会员信息为例：
‘User-133-age’ 22
‘user-133-height’ 170
‘user-89-age’ 60
‘user-89-height’ 182
当服务器增多，133号用户的信息也被散落在更多的服务器，所以，同样是访问个人主页，得到的相同的个人信息，节点越多，要连接的节点也越多，对于memcached的连接数，并没有随着节点的增多而降低，问题出现。
用一句通俗的话总结：更多的机器不代表更多的性能，所谓“无底洞”就是说投入越多不一定产出越多。
分布式又是不可以避免的，因为我们的网站访问量和数据量越来越大，一个实例根本坑不住，所以如何高效的在分布式缓存和存储批量获取数据是一个难点。
一个较为简单的解决方案：
NoSQL和传统的RDBMS，并不是水火不容，两者在某些设计上，是可以相互参考的。对于memcached,Redis,这种kv存储，key的设计，可以参考MySQL中表与列的设计。
比如：user表下有age列,name列,身高列，对应的key，可以用user:133:age=23,user:133:name=’lisi’,user:133:height=168;
可以将某一组key，按其共同前缀来分布，比如按照’user-133’来计算，而不是以user-133-age，user-133-name，user-133-height来计算，这样3个关于个人信息的key，都落在同一个节点，访问个人主页时，只需连接一个节点。
永久数据被踢现象
在实际使用中，常常有人发现，自己设置的永久数据，莫名其妙的丢失了。
其实，这要从两个方面来考虑：
- memcache的惰性删除机制
- LRU算法淘汰机制
关于上述两种机制，前面说memcache的删除机制时有提过
通俗理解：
- 数据在内存中失效后，并不会立马被删除，只有在下次get时候，系统才会将其删除。
- Memcache可以因此，被一些未被及时删除的数据占满空间。
- 加之LRU淘汰机制，永久数据如果很少被访问的话，在内存空间被占满的情况下，再有新数据被缓存，则永久数据，就有可能被删除。
解决方案：
永久数据和非永久数据分开放。