三.缓存雪崩现象和无底洞现象

一.缓存雪崩现象

一般是有某个节点失效，导致其他节点的缓存命中率下降，缓存中缺失的数据去数据库查询，短时间内，造成数据库服务器崩溃
重启DB，短时间又被压垮，但缓存数据也多了一些，DB反复多次启动，缓存重建完毕，DB才稳定运行

案例：
一个上千万PV的门户网站，缓存生命周期设置了6小时，当等到6小时缓存失效后，之前放到缓存的数据，都转到DB中查询，这时候，DB的压力急剧上升，最后导致DB崩溃

解决方法：
1.将缓存时间设置的更长，等到半夜网站访问量少的时候，进行全部缓存的更新
2.将缓存时间设置在随机3-9小时的范围内，这样，缓存就不会同时失效，可以减少同一时间缓存失效量，减少对DB的压力

二.无底洞现象

facebook工作人员反应，facebook在2010年左右，memcached节点已经达到3000个，他们发现了一个问题：memcached连接频繁，导致效率下降，于是加memcached节点，添加后发现因为连接频繁导致的效率问题依然存在，这就被称为“无底洞现象”。

问题分析：
以用户为例：user-133-age,user-133-name,user-133-height….N个key,当服务器增多，133用户的信息，也被散落到更多的节点，所以，同样是访问个人主页，得到相同的个人信息，节点越多，要连接的节点越多，对于memcached的连接数，并没有随着节点的增多，而减少，问题出现了

事实上：
Nosql与传统的RDBMS并不是水火不容，两者在某些设计上，是可以相互参考的，对于memcacede、redis这种kv存储，key的设计，可以参考Mysql中表/列的设计

例如：user表，有age、name、height列

例子：对应的key，可以用user:133:age = 23, user:133:name=’lisi’

问题解决方案：
把某一组key，按其共同前缀来分布：
例如：user:133-age,user-133-height这两个key
在用分布式算法求其节点时，应该以‘user-133’来计算，而是已”user-133-age/name’来计算
这样，两个关于个人信息的key，就落到同一个节点上