三.缓存雪崩现象和无底洞现象
来源:互联网 发布:淘宝上的生发液有用吗 编辑:程序博客网 时间:2024/04/30 22:55
一.缓存雪崩现象
一般是有某个节点失效,导致其他节点的缓存命中率下降,缓存中缺失的数据去数据库查询,短时间内,造成数据库服务器崩溃
重启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,就落到同一个节点上
- 三.缓存雪崩现象和无底洞现象
- Memcached缓存无底洞现象
- 缓存无底洞现象
- Memcached缓存无底洞现象
- Memcached缓存雪崩现象
- 缓存雪崩现象
- memcache缓存雪崩现象
- MemCache缓存雪崩现象
- memcache与redis lru 一致性hash 缓存雪崩 缓存无底洞 永久数据被踢现象
- memcache 缓存雪崩现象及解决方法
- memcache缓冲雪崩现象
- Memcache 雪崩现象
- memcache缓冲雪崩现象
- memcache 雪崩现象
- memcache常见现象(一)雪崩现象
- Memcache线上常见问题(缓存雪崩、缓存无底洞、永久数据被踢)
- 现象和本质
- Latchup现象和预防措施
- Dedecms方法 html2wml 设计缺陷,造成wap版超过10张照片的时候丢失
- Android填坑之旅(第一篇) 关于应用文本太长为用户提供复制的功能
- windows 安装git
- 原生javascript图片懒加载效果代码。
- keil C
- 三.缓存雪崩现象和无底洞现象
- 3——管道
- Linux中find常见用法示例
- activiti 工作流 web 流程设计器 SSM activiti工作流
- js代码回收机制
- 五分钟理解Java的反射API
- activity启动模式探究
- iOS 基于环信SDK实现即时通讯-语音、视频聊天
- Android Eclipse Unable to execute dex: Multiple dex files define