如何设计一个系统的 Redis 缓存以提高吞吐量和防止缓存雪崩?

每天来一次技术“灵魂”的考验。

对于一个业务复杂、高并发和大流量的系统,缓存是重要组成部分,提升系统性能的主要方式之一就是缓存。它可以挡掉大部分的数据库访问的冲击,如果没有它,系统很可能会因为数据库不可用导致整个系统崩溃。

缓存带来了另外一些棘手的问题:数据的一致性和实时性

例如,数据库中的数据状态已经改变,但是在页面上看到的仍然是缓存的旧值,直到缓冲时间失效之后,才能重新更新缓存。这个问题怎么解决?

还有缓存数据如果没有失效的话,是会一直保持在内存中的,所以对服务器的内存也是负担,那么什么数据可以放缓存,什么数据不可以,这是系统设计之初必须考虑的问题。

什么数据可以放缓存?

1,不需要实时更新但是又极其消耗数据库的数据。比如网站首页的商品销售的排行榜,热搜商品等等,这些数据基本上都是一天统计一次,用户不会关注其是否是实时的。

2,需要实时更新,但是数据更新的频率不高的数据。

3,每次获取这些数据都经过复杂的处理逻辑,比如生成报表。

什么数据不应该使用缓存?

实际上,在电商系统中,大部分数据都是可以缓存的,不能使用缓存的数据很少。这类数据包括比如涉及到钱、密钥、业务关键性核心数据等。总之,如果你发现,系统里面的大部分数据都不能使用缓存,这说明架构本身出了问题。

如何解决一致性和实时性的问题?

保证一致性和实时性的办法就是:一旦数据库更新了,就必须把原来的缓存更新。

说一说我们的缓存方案

我们目前的缓存系统:Redis(主从)+ RabbitMQ + 缓存清理服务组成,具体如下图:

缓存清理作业订阅 RabbitMQ消息队列,一有数据更新进入队列,就将数据重新更新到Redis缓存服务器。

当然,有些朋友的方案,是数据库更新完成之后,立马去更新相关缓存数据。这样就不需要MQ 和 缓存清理作业。不过,这同时也增加了系统的耦合性。具体得看自己的业务场景和平台大小。

缓存雪崩

缓存雪崩是由于原有缓存失效(过期),新缓存未到期间。所有请求都去查询数据库,而对数据库 CPU 和内存造成巨大压力,严重的会造成数据库宕机。从而形成一系列连锁反应,造成整个系统崩溃。

1. 碰到这种情况,一般并发量不是特别多的时候,使用最多的解决方案是加锁排队。

2. 加锁排队只是为了减轻数据库的压力,并没有提高系统吞吐量。

假设在高并发下,缓存重建期间key是锁着的,这是过来1000个请求999个都在阻塞的。同样会导致用户等待超时,这是个治标不治本的方法。

3. 给每一个缓存数据增加相应的缓存标记,记录缓存的是否失效,如果缓存标记失效,则更新数据缓存。

缓存标记:记录缓存数据是否过期,如果过期会触发通知另外的线程在后台去更新实际key的缓存。

缓存数据:它的过期时间比缓存标记的时间延长1倍,例:标记缓存时间30分钟,数据缓存设置为60分钟。 这样当缓存标记 key 过期后,实际缓存还能把旧数据返回给调用端,直到另外的线程在后台更新完成后,才会返回新缓存。

这样做后,可以一定程度上提高系统吞吐量。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180918G0CAGJ00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

同媒体快讯

扫码关注云+社区

领取腾讯云代金券