缓存在分布式系统中应用广泛,如何在架构设计中使用缓存来优化业务一直都是一个重要的话题。本文主要对引入缓存需要解决的问题以及一些优秀的实践,让读者对缓存有一个比较宏观的了解。
缓存对性能的提升十分明显,特别是在分布式系统中,80%的业务访问集中在20%的数据上,如何用好缓存是架构设计的必修课。
目前,很多系统框架可能会涉及到方方面面,如下图所示:
从客户端访问,到最终的数据存储,整个流程中有各式各样的缓存,主要有如下几个部分:
本质
空间换时间 - 利用分布式下不同介质的快速存储设备,来替换数据库,加快系统的数据处理和响应速度。
就近原则 - 将数据缓存到离用户最近的位置;将数据缓存到离应用最近的位置。
引入缓存我们获取的数据的过程就变成如图所示:
引入一方面减轻了数据库的压力、提升查询性能、提供吞吐量,但同时也要考虑诸多带来的问题,如:
接下来,我们一个个来看看。
1、缓存穿透
缓存穿透指的是使用不存在的key进行大量的高并发查询,这导致缓存无法命中。每次请求都要穿透到后端数据库系统进行查询,使数据库压力过大,甚至使数据库被压死。
从缓存视角看无法在缓存中找到记录;从数据库视角看无法在数据库中找到记录。缓存穿透的解决方法,可以通过空对象(NullObject)或者 布隆过滤器来解决。
我们通常将空值缓存起来,再次接收到同样的查询请求时。若命中缓存并且值为空对象,就会转换成业务需要的结果返回(包含错误码和结果不存在的错误信息),这样就不会透传到数据库,避免缓存穿透。
将所有可能存在的数据哈希到一个足够大的bitmap中去,不存在的数据会被bitmap拦截,从而避免了对底层存储系统的压力。
布隆过滤器可以使用Guava来做,一个简单的示例如下:
import com.google.common.hash.BloomFilter;
import com.google.common.hash.Funnels;
public class Test {
public static void main(String[] args) {
BloomFilter<Integer> filter = BloomFilter.create(Funnels.integerFunnel(), 50000000L);
for(int i=1;i<2000000;i++) {
filter.put(i);
}
int mightContainsNum = 0;
for(int i=1;i<2000000;i++) {
if(filter.mightContain(i)) {
mightContainsNum++;
}
}
System.out.println("匹配数 : " + mightContainsNum);
}
}
2、缓存雪崩
缓存雪崩指在服务器重启或者大量缓存集中在某一个时间段内失效,给后端数据库造成瞬时的负载升高的压力,甚至压垮数据库的情况。
缓存雪崩一个简单有效的解决方法就是设置不同的失效时间。通常的解决办法是对不同的数据使用不同的失效时间。比如我们要缓存一个Product的数据,会对每个产品的缓存数据设置不同的缓存过期时间。可以定义一个基础时间,假设是30分钟,然后加上一个5分钟的随机数据,缓存数据将被打散,失效时间为30~35之间,这样就会避免缓存雪崩。
其他解决方法包括使用二级缓存,缓存不过期(可以通过其他定时或者某种策略来删除)等。
3、缓存并发
缓存并发的问题通常发生在高并发的场景下,当一个缓存key过期时候,因为访问这个缓存key的请求量较大,多个请求同时发现缓存过期。因此多个请求会同时访问数据库来查询最新的数据,并且写回缓存,这样造成应用和数据库的负载增加,性能降低。
缓存并发可以通过分布式锁、软过期等方法解决。
使用分布式锁,保证对每个key同时只有一个线程去查询后端服务,其他线程没有获得分布式锁的权限,因此只需要等待即可。这种方式将高并发的压力转移到了分布式锁,因此对分布式锁的考验很大。
对缓存的数据设置失效时间,就是不使用缓存服务提供的过期时间,而是业务在数据存储过期时间信息,由业务程序判断是否过期并更新,在发现了数据即将过期时,将缓存的失效延长,程序可以派遣一个线程去数据库获取最新的数据,其他线程这时看到了延长了的过期时间,就会继续使用旧数据,等派遣的线程获取最新数据后再更新缓存。
其它解决方法入手多级缓存、永不过期等。
4、一致性问题
当数据变化时候,为了去保持数据库和缓存数据的一致性,数据库和缓存处理的方式主要有2种:
方法1:先删除缓存,再更新数据库
方法2:先更新数据库,再删除缓存(个人使用这个,推荐)
理由
1、原子性考量
2、因为如果删除缓存成功,更新数据库失败,最多只是会造成缓存穿透,引起一次Cache miss,后面还会更新缓存。而如果更新数据库成功,删除缓存失败,会引起比较严重的数据不一致情况。
有很多同学选择该方式来处理,原因主要是如上所述吧。
但是,这个在并发的场景中,两个并发操作,一个是更新操作,另一个是查询操作,更新操作删除缓存后,查询操作没有命中缓存,先把老数据读出来后放到缓存中,然后更新操作更新了数据库。于是,在缓存中的数据还是老的数据,导致缓存中的数据是脏的,而且还一直这样脏下去了。
这种方式也是有数据不一致的场景存在,当然可以通过双删除的方式解决,即更新数据库后再删除一次缓存。
我为什么没有选择这种方式,主要还是因为,我觉得数据还是要以数据库的数据为准,缓存应该是个辅助,其操作成功不意味着最终真正的成功。写缓存失败就不再写数据库,虽然保证了原子性,但这种做法对比较影响业务。所以,个人还是比较倾向于方法二:先更新数据库,再删除缓存。
注
这里使用的是删除del而不是set,之所以这样是怕两个并发的写操作导致脏数据。
这种主要采用了Cache Aside Patter, 其主要的思想是:
该种处理方式基本没有很大的并发问题,其造成脏数据的情况相对概率相对较低,因为这个条件需要发生在读缓存时缓存失效,而且并发着有一个写操作。
脏数据场景
一个是读操作,但是没有命中缓存,然后就到数据库中取数据,此时来了一个写操作,写完数据库后,让缓存失效,然后,之前的那个读操作再把老的数据放进去,所以,会造成脏数据。
不过,这种情况下,还有其它的问题,比如如下情况:
针对读写分离的场景,我们可以对某些表进行设置,就从主库读取即可获取最新的数据。针对缓存删除失败的场景,可以引入消息队列,让业务收发消息队列,然后重试删除。
这种方式,业务逻辑需要考虑缓存失败的逻辑处理,对代码有侵入性。那么,有没有什么手段去让业务层只关注业务,而不需要考虑缓存的失效?
可以借助Canal,来完成数据库binlog的订阅,然后完成缓存的更新操作,如:
这样处理之后,业务层就关注业务,缓存失效由非业务代码来处理,这样就分开了,如下图所示:
补充
关于先更新数据库还是先删除缓存,这些还是要根据自己的业务场景、特点来选择。个人而言,我更加倾向于【先更新数据库,后删除缓存】的方式。
5、本地缓存
在很多场景中,我们还会引入本地缓存(比如采用Guava来做),以增加查询效率。
场景
有两个(dubbo)应用product和device,其中:
product服务接口提供中获取产品详情的方法,包含产品基本信息定义,以及包含的数据点等定义。
device服务需要使用到获取product的获取产品详情方法。
在上述场景中,详情的获取是这样的device -->product --> 缓存,
因为产品的定义修改是低频的,所以如果在device中增加product详情的本地缓存,将减少调用product服务的次数,减少网络带来的开销,提升device相关接口的效率。
引入本地缓存后,变成如下模样。
这样一来,本地查询是加快了,但是同时也带来了如下的问题:
如果产品信息更新,分布式环境下device的应用服务可能有几十个,每个device应用中的本地缓存如何同步更新?
一个较靠谱的解决方法便是引入消息队列进行通知,采用广播的方式。
6、缓存的对象扩展
思考
前期对某个对象(如产品Product)进行了缓存,缓存对象包含产品的名称、productKey。现在需要在该缓存对象中增加一个所述品类的的信息,需要在原来的基础上进行扩容。
上线发布需要注意些什么呢?
解决方法:
7、版本升级,数据迁移
思考
Redis版本需要升级,比如4.0升级到5.0,需要进行数据迁移。
如何做呢?
这个时候需要考虑业务场景了,是否是静态迁移还是动态迁移。
静态迁移(需要做好评估,一般在晚上交易量小或者非核心业务场景中用)
如果不能停机,进行数据迁移如何做呢?
平滑迁移(适合对可用性要求较高的场景,如停机会带来较大损失,无交易低峰)
温馨提示
缓存是一个大的课题,可以做的事情很多,比如优化、稳定性等。
所谓技无止境,没有最好只有更好。在不同的场景,使用缓存可能会遇到这样那样的问题,还需要选择合适的方式去解决。
参考资料
[1]. https://www.cnblogs.com/jay-huaxiao/p/11462232.html
[2]. https://www.cnblogs.com/fanguangdexiaoyuer/p/9545181.html
[3]. https://blog.csdn.net/chuanyingcao2675/article/details/101048933
[4]. 李艳鹏等. 可伸缩服务架构-框架与中间件. 电子工业出版社
[5]. https://coolshell.cn/articles/17416.html