缓存常见问题及分析

2018-02-27 11:18:11来源:https://www.jianshu.com/p/7aa091d97bc8作者:勇敢的_心_人点击

分享


1 使用场景

什么情况下适合使用缓存?


短时间内相同数据被重复查询且更新频率不高,这种情况可以考虑使用缓存。应用先查询缓存,如果查询不到数据,则从数据库加载该数据并保存到缓存;
高并发热点数据,完全透传到数据库会造成数据库宕机,必须使用缓存;
什么情况下不建议使用缓存?


配置型数据在不频繁读的情况下(数据库url等),可以不使用缓存。这类数据建议使用配置中心的方式主动推送;
实时性要求较高的数据,不建议使用缓存。比如用户密码,一般只用来做登录校验,不会频繁读取,缓存该数据并不能大幅提升系统性能,还可能导致用户密码修改后不能及时生效从而影响用户体验(缓存更新失败的情况);


2 缓存选型

开发中常用的缓存有本地缓存和分布式缓存。可以用HashMap自己实现一个简单的本地缓存,也可以用Guava cache或者ehcache来实现。对于分布式缓存,业界常用的有redis、memcached、还有阿里的tair等。


什么情况适合本地缓存?
频繁被访问的大对象。分布式缓存需要跨进程访问数据,缓存服务器需要先序列化该对象,通过网络传输到应用服务器,然后应用服务器再反序列化,而序列化与反序列化的过程是非常消耗CPU的操作。
数据量小的单机应用;


什么情况适合分布式缓存?
大数据量的缓存,数据频繁的增长又清空(本地缓存会导致频繁的垃圾回收);
分布式应用,多个应用实例访问同一份缓存数据;


3 数据数据更新

因为缓存和数据库是两个独立的组件,两者无法在同一个本地事务内完成更新,所以在写的时候有可能会出现数据不一致的情况。不考虑分布式事务的前提下,有下面几种更新策略:


先删除缓存,再更新数据库
case1:低并发场景下,先删除缓存,更新数据库后,后续读操作会从数据库读取数据并更新缓存,仅会造成一次缓存未命中;
case2:高并发场景下,写线程T1先删除缓存数据,读线程T2未命中缓存,从数据库读取数据并加载到缓存,然后线程T1更新数据库数据。这时缓存中的值就是原来的老数据,后续读操作都属于脏读。


先更新数据库,再删除缓存
case3:先更新数据库,再删除缓存,在删除缓存失败的情况下,也会出现脏数据;
case4:缓存数据失效的瞬间,读线程T1未命中缓存,然后到数据库取数据,取完数据后来了个写线程T2,T2先往数据库写数据,然后删除缓存,接着T1再把读到的老数据加载到缓存,此时也会造成脏读。这个情况出现的概率非常低,需要缓存失效的瞬间有并发的读写操作。而且数据库的写会比读慢很多,并且需要对数据加锁,所以T1必须在T2之前进入数据库进行操作,又要晚于T2更新缓存,所有这些条件都具备的概率非常低。


先更新数据库,再更新缓存
case5:假设两个写线程T1、T2并发更新某一数据,T1先获取锁、更新数据库并且释放锁,T2获取锁、更新数据库然后释放锁;接下来T2更新缓存值,T1更新缓存值,这时候缓存中的数据T1为脏数据。
不考虑缓存和数据库操作失败的情况,case4产生脏数据的概率最小。再接合缓存数据的自动过期,该方案适合成为缓存更新的通用策略。


4 缓存击穿

缓存击穿可以分为以下几种情况:


查询数据库中不存在的值,每次都会访问数据库,如果有人恶意攻击则会对数据库造成很大压力。


解决方案:
对于数据库中不存在的key-value查询,在缓存中为该key设置一个默认value。该value需要具有明显特征,不能干扰正常业务(比如”NULL”);
使用布隆过滤器,大部分在数据库中不存在的查询请求会被该过滤器直接过滤,不会透传到数据库层。


数据缓存时间到期,失效瞬间多个线程/进程查询数据,则每个请求都会执行查询数据库,然后设置缓存的动作。如果该查询是热点key查询,数据库压力会瞬间增大。


解决方案:
请求查询数据库前先获取分布式互斥锁,取得锁的进程A查询数据库并设置缓存中的值,其余线程等待线程A执行完毕后从缓存中读取值。


public String getValue(String key) {
String retValue = getValueFromCache(key);

if(null != retValue) {
return retValue;
}

lock = getMutexLock(key);
try {
retValue = getValueFromCache(key);
if(null == retValue) {
retValue = getValueFromDB(key);
setCache(key, retValue);
}
}
finally {
unlock(key);
}

return retValue;
}

如果使用本地缓存,可以用guava代替上述功能,guava默认支持多线程的并发访问。


Cache<Key, Object> cache = CacheBuilder.newBuilder().maximumSize(1000).build();
try {
cache.get(key, new Callable<Key, Object>() {
@Override
public Object call() throws AnyException {
return getFromDB(key);
}
});
} catch (ExecutionException e) {
throw new OtherException(e.getCause());
}

5 热点key

业务高峰期,大量请求访问同一份数据,hash算法使得相同key的所有流量涌向同一台机器,这台机器成为系统瓶颈,该问题的挑战在于它无法通过增加机器容量来解决。
解决热点问题最有效的方法是从业务角度将热点拆分,对于某些不能拆分的业务,可以采取多份数据的形式分担负载。这类方案通过牺牲数据一致性来提高效率。


客户端本地缓存
热点数据缓存在客户端本地,并设置一个较短的过期时间,每次读请求先检查本地缓存。本地缓存中有数据则直接返回;如果不能命中本地缓存,再去访问分布式缓存服务器。该方案的缺点是分布式缓存数据更改后不能及时刷新本地缓存,造成数据脏读,如果业务可以容忍短时间内数据不准确,可以使用本方案。


数据多读多写
将热点key散列为多个子key,子key被hash到缓存集群的不同机器上,读数据的时候随机选择一个子key访问对应的缓存服务器,写数据的时候要更新该key对应的所有子key值。
假设某个热点key被散列为N个子key,缓存服务器的数量M>N,最理想的情况下,缓存服务器压力会降低到单key的1/N。
该方案需要业务提前感知热点key或者采用具有统计hotkey能力的缓存服务器,同时更新N份缓存数据也存在部分失败的风险,业务需要容忍短时间内的数据不一致。


6 缓存预热

缓存预热是指在用户可访问服务之前,将热点数据加载到缓存的操作,这样可以有效避免上线后瞬时大流量造成系统不可用。








最新文章

123

最新摄影

闪念基因

微信扫一扫

第七城市微信公众平台