MC的缓存雪崩现象和缓存无底洞的原因以及导致的后果的总结
缓存雪崩一般是由某个缓存节点失效,导致其他节点的缓存命中率下降,缓存中确实的数据去数据库查询,短时间内,造成数据库服务器的崩溃。
这时,我们需要重启数据库,但重启一段时间后,又会被压垮,但此时缓存的数据也比之前要多。
这样,反复几次重启数据库,缓存才重建完成,数据库才稳定的运行。
或者,是由于缓存周期性的失效,比如每6个小时失效一次,那么每6个小时,将有一个请求的峰值,严重者设置会令数据库崩溃。
可以看下面的这幅统计图,是数据库的访问量统计图:
可以看到,缓存每6个小时就失效一次,每过6个小时就到了一次请求的高峰时期,那这样的话,每过6个小时数据库就会崩溃一次的。
我们可以采用的解决方案是:
可以把缓存设置的失效的时间设置为3到9小时的生命周期,这样不同时失效,把工作分担到各个时间点上去
缓存无底洞现象:
该问题由facebook的工作人员提出的,facebook在2010年左右,memcached节点就已经达
3000个.缓存数千G内容.
他们发现了一个问题---memcached连接频率,效率下降了,于是加memcached节点,
添加了后,发现因为连接频率导致的问题,仍然存在,并没有好转,称之为”无底洞现象”.
multiget-hole的问题分析:
以用户为例:user-133-age,user-133-name,user-133-height ... N个ke,当服务器增多的时候,133号用户的信息,也被更散落在更多的节点上,所以,同样是访问个人主页,得到相同的个人信息,节点越多,要连接的节点也越多,对于memecached的连接数,并没有随着节点的增多,而降低。于是出现了无底洞现象。
multiget-hole的解决方案:
把某组key,按其共同前缀,来进行分布:
比如 user-133-age,user-133-name,user-133-height 这3个key,在使用分布式计算法求其节点时,应该以‘user-133’来进行计算,而不是以 user-133-age/name/height来进行计算。
这样,3个关于个人信息的key,都落在同1个节点上,访问个人主页时,只需要连接1个节点.问题得到解决
事实上:
NoSQL和传统的RDBMS,并不是水火不容,两者在某些设计上,是可以相互参考的. 对于memcached,redis这种kv存储,key的设计,可以参考MySQL中表/列的设计. 比如:user表下,有age列,name列,身高列,
对应的key,可以用user::age=,user::name=‘lisi’,user::height=;
最新文章
- curl php 小记
- [转]关于jquery中html()、text()、val()的区别
- 用单分子测序(single-molecule sequencing)和局部敏感哈希(locality-sensitive hashing)来组装大型基因组
- 专题:mdadm Raid &; LVM
- EXCEL某列长度超过255个字符导入SQL SERVER的处理方法
- IT应届生如何准备找工作?
- Html辅助方法(分页、下拉框)
- bzoj 3223/tyvj 1729 文艺平衡树 splay tree
- Java面试汇总
- Android最新锁屏病毒分析及解锁
- Custom Properties for Alert Description and Notification(PropertyBag)
- 【HDOJ】5564 Clarke and digits
- solr 搜索引擎及搜索推荐应用
- Centos安装vncserver服务
- 浙大pat 1059 题解
- nefu 115 斐波那契的整除
- wampserve部署
- 【BZOJ1189】紧急疏散(二分答案,最大流)
- git submodule 删除及更新URL 转载的
- 【CodeForces】983 E. NN country 树上倍增+二维数点