Memcached在实战中碰到的经典问题和现象
缓存雪崩现象
一般是由某个节点失效，导致其他节点的缓存命中率下降
缓存中缺失的数据去数据库查询，短时间内，造成数据库服务器崩溃
重启DB，短期又被压垮，但缓存数据也多一些
DB反复多次启动多次，缓存重建完毕，DB才稳定运行
或者是由于缓存周期性失效，比如每6小时失效一次，那么每6小时，将有一个请求“峰值”，严重者甚至会令DB崩溃
解决方案：
a)把缓存设置为随机3到9小时的生命周期，这样不同时失效，把工作分担到各个时间点上去
缓存无底洞现象
facebook的工作人员反映的，facebook在2010年左右，memcached节点就已经达3000个。存储数千G的缓存
他们发现了一个问题---memcached连接频率，效率下降了，于是加memcached节点
添加了后，发现因为连接频率导致的问题，仍然存在，并没有好转
称之为“无底洞现象”
问题分析：
以用户为例：user-133-age,user-133-name,user-133-height....N个key
当服务器增多：133号用户的信息，也被散落在更多的服务器
所以，同样是访问个人主页，得到相同的个人信息，服务器越多，要连接的服务器也越多
对于memcached的连接数，并没有随着节点的增多而降低，问题出现
事实上：
NoSQL和传统的RDBMS并不是水火不容，两者在某些设计上是可以相互参考的
对于memcached、redis这种kv存储，Key的设计，可以参考 MYSQL中表/列的设计
比如：user表下，有age列，name列，身高列
对应的Key，可以用user:133:age=23,user:133:name='lisi'，user:133:height=175
问题解决方案：
把某一组key，按其共同前缀来分布
比如user-133-age,user-133-name,user-133-height.这三个Key
在用分布式算法求其结点时，应该以user-133来计算，而不是以User-133-age/name/height来计算
这样
这样，3个关于个人信息的key都落在同一个节点上，访问个人主页时，就只需要连接一个节点
问题解决
永久数据被踢现象
memcached标记为永久有效，缺莫名其妙丢失了？
思路：根据自己的服务器参数，选择某1个chunk大小
比如，我的memcached观察到size为8880Byte的chunk单元有118个
因此，我设置8880长度的字符串，往里存入
第一个设置为永久有效，其他117个，设置为20秒
get后117个items使其活跃，然后再增加第119个items，观察谁丢失了？
永久数据被踢现象：两个方面原因：惰性删除与LRU(最近最少使用记录删除)
提示：
1、数据在内存中并未真正删除，系统也不知道某个item已失效，下次去get他时才知道失效，才把chunk清空
2、如过slab里面的很多chunk都已经过期但是没有get过，系统不知道他们已经过期。
3、永久数据很久没get了，不活跃，如果新增item，则永久数据被踢了...
4、如果哪些非永久数据频繁被get也会标志位expire，从而不会再踢掉永久数据
官方解决方案：永久数据和非永久数据分开放
memcached与Mysql数据同步
redis与Mysql数据同步
缓存和数据库一致性解决方案