缓存雪崩现象

一般是由于某个节点失效,导致其它节点的缓存命中率下降,缓存中缺失的数据直接去数据库查询,短时间内造成数据库服务器崩溃。

或者是由于缓存周期性失效,比如设置每隔6个小时失效一次,那么每6个小时将会有一个请求峰值,严重的话,也会导致数据库崩溃。

重启DB后,短期内又被压垮,但缓存又会恢复一点,DB反复重启多次,直至缓存重建完毕,才能恢复稳定。


Memcache线上常见问题(缓存雪崩、缓存无底洞、永久数据被踢)

如果小网站,平时访问量不大的情况下,数据缓存的时间不同,失效时间也不同,可能不会出现此问题。而对于一些访问量较大的网站,可能memcache一开起,瞬间几万次,甚至几千万次的同时访问,短期内就会缓存完所有的,也就会导致近似同时失效,出现上述这种后果。

解决方案:

缓存有效期随机设置3-9小时之间的一个随机值。控制缓存在闲时过期(比如夜里)。
缓存无底洞现象

Facebook的工作人员反应2010年已达到3000个memcached节点,储存数千G的缓存。

他们发现一个问题–memcached的连接效率下降了,于是增加了Memcache节点,添加之后,发现因为连接频率导致的问题,仍然存在看,并没有好转。

原文请见: http://highscalability.com/blog/2009/10/26/facebooks-memcached-multiget-hole-more-machines-more-capacit.html

以会员信息为例:

‘User-133-age’ 22

‘user-133-height’ 170

‘user-89-age’ 60

‘user-89-height’ 182

当服务器增多,133号用户的信息也被散落在更多的服务器,所以,同样是访问个人主页,得到的相同的个人信息,节点越多,要连接的节点也越多,对于memcached的连接数,并没有随着节点的增多而降低,问题出现。


Memcache线上常见问题(缓存雪崩、缓存无底洞、永久数据被踢)
Memcache线上常见问题(缓存雪崩、缓存无底洞、永久数据被踢)

用一句通俗的话总结:更多的机器不代表更多的性能,所谓“无底洞”就是说投入越多不一定产出越多。

分布式又是不可以避免的,因为我们的网站访问量和数据量越来越大,一个实例根本坑不住,所以如何高效的在分布式缓存和存储批量获取数据是一个难点。

一个较为简单的解决方案:

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算法淘汰机制

通俗理解:

数据在内存中失效后,并不会立马被删除,只有在下次get时候,系统才会将其删除。 Memcache可以因此,被一些未被及时删除的数据占满空间。加之LRU淘汰机制,永久数据如果很少被访问的话,在内存空间被占满的情况下,再有新数据被缓存,则永久数据,就有可能被删除。

解决方案:

永久数据和非永久数据分开放。

上述仅按照个人理解所写,解决方案并不仅限于此,如有不当之处,敬请指出。

本文数据库(综合)相关术语:系统安全软件

分页:12
转载请注明
本文标题:Memcache线上常见问题(缓存雪崩、缓存无底洞、永久数据被踢)
本站链接:http://www.codesec.net/view/483652.html
分享请点击:


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 数据库(综合) | 评论(0) | 阅读(22)