您的位置:首页 > 数据库 > Memcache

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

2016-10-15 11:51 399 查看

缓存雪崩现象

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

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

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



如果小网站,平时访问量不大的情况下,数据缓存的时间不同,失效时间也不同,可能不会出现此问题。而对于一些访问量较大的网站,可能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的连接数,并没有随着节点的增多而降低,问题出现。





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

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

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

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

关于上述两种机制,详见:http://blog.csdn.net/qq_28602957/article/details/52799117

通俗理解:

数据在内存中失效后,并不会立马被删除,只有在下次get时候,系统才会将其删除。

Memcache可以因此,被一些未被及时删除的数据占满空间。

加之LRU淘汰机制,永久数据如果很少被访问的话,在内存空间被占满的情况下,再有新数据被缓存,则永久数据,就有可能被删除。

解决方案:

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

上述仅按照个人理解所写,解决方案并不仅限于此,如有不当之处,敬请指出。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息