通常的缓存系统,都是按照key去缓存查询,若是不存在对应的value,就应该去后端系统查找(好比DB)。若是key对应的value是必定不存在的,而且对该key并发请求量很大,就会对后端系统形成很大的压力。这就叫作缓存穿透。redis
1:对查询结果为空的状况也进行缓存,缓存时间设置短一点,或者该key对应的数据insert了以后清理缓存。数据库
2:对必定不存在的key进行过滤。能够把全部的可能存在的key放到一个大的Bitmap中,查询时经过该bitmap过滤。后端
3: 即使DB查询结果为空,也能够将这个key的缓存值设为null,以减小缓存的压力。缓存
当缓存服务器重启或者大量缓存集中在某一个时间段失效,这样在失效的时候,也会给后端系统(好比DB)带来很大压力。服务器
1:在缓存失效后,经过加锁或者队列来控制读数据库写缓存的线程数量。好比对某个key只容许一个线程查询数据和写缓存,其余线程等待。并发
2:不一样的key,设置不一样的过时时间,让缓存失效的时间点尽可能均匀。分布式
3:作二级缓存,A1为原始缓存,A2为拷贝缓存,A1失效时,能够访问A2,A1缓存失效时间设置为短时间,A2设置为长期spa
A.根据业务统计的维度或是场景,创建一张以JSON格式为模板的表;线程
B.经过调度平台,定时地逐个访问一遍全部的key,将值保存至模板表中和缓存集群中;继承
C.不断对2进行轮询,保持key-value的热度和完整性;
D.用户请求过来,先访问咱们的缓存,一旦缓存失效或是重启,直接从数据库模板表中获取最新的热度数据并缓存,这样咱们就能有效的减轻数据库的压力;
E.这也是一种缓存预热的方案;
1:缓存系统与底层数据的一致性。这点在底层系统是“可读可写”时,显得尤其重要。
2:有继承关系的缓存之间的一致性。为了尽可能提升缓存命中率,缓存也是分层:全局缓存,二级缓存。它们是存在继承关系的。全局缓存能够由二级缓存来组成。
3:多个缓存副本之间的一致性。为了保证系统的高可用性,缓存系统背后每每会接两套存储系统(如memcache,redis等)
上面有讲述。
缓存淘汰的策略有两种: (1) 定时去清理过时的缓存。 (2)当有用户请求过来时,判断这个请求所用到的缓存是否过时,过时的话就去底层系统获得新数据并更新缓存。
二者各有优劣,第一种的缺点是维护大量缓存的key是比较麻烦的,第二种的缺点就是每次用户请求过来都要判断缓存失效,逻辑相对比较复杂,具体用哪一种方案,你们能够根据本身的应用场景来权衡。
1. 预估失效时间 2. 版本号(必须单调递增,时间戳是最好的选择)3. 提供手动清理缓存的接口。