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

待我称王封你为后i 2022-07-16 10:39 244阅读 0赞

# 缓存雪崩现象 #

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

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

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

![示例][20161015113202497]

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

![示例][20161015113715880]

![示例][20161015113730443]

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

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

--------------------

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

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][http_blog.csdn.net_qq_28602957_article_details_52799117]

通俗理解：

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

解决方案：

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

--------------------

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

--------------------

[20161015113202497]: /images/20220716/91801de0e2134a5f840174c4896c6ece.png
[http_highscalability.com_blog_2009_10_26_facebooks-memcached-multiget-hole-more-machines-more-capacit.html]: http://highscalability.com/blog/2009/10/26/facebooks-memcached-multiget-hole-more-machines-more-capacit.html
[20161015113715880]: /images/20220716/1c631597032e432988d7fc91bb99423a.png
[20161015113730443]: /images/20220716/b07dca75ee194847baa56abbe6f74435.png
[http_blog.csdn.net_qq_28602957_article_details_52799117]: http://blog.csdn.net/qq_28602957/article/details/52799117