缓存类别
1.线程级缓存:ThreadLocal
适用场景:同个线程内需要多次请求耗时接口,例如需要根据权限范围查询具体数据,多次查权限。
2.单机缓存:GuavaCache
适用场景:数据量较少,请求频率高。
3.分布式缓存:Redis
适用场景:
缓存遇到的问题
缓存并发
现象:热点key并发量高。当key过期时,同一时刻会有多个请求打到db,影响db性能。
解决方案:
1.当key不存在需要查询db时加锁,获取到锁的线程才能查db。其余线程自旋等待。
2.GuavaCache中expireAfterWrite当某个key失效时,第一个线程会锁住当前key所在的segment,其余线程等待,容易造成多线程阻塞。可以通过refreshAfterWrite解决,定时更新缓存。当缓存失效时,只有第一个线程从db捞数据,其余线程直接返回旧数据。
缓存雪崩
现象:在同一时刻缓存中有多个key失效时,多个请求直接打到db,导致db负载过高。
解决方案:初始化缓存时,过期时间设置成定时+随机时间,避免大量key同一时刻失效。
缓存穿透
现象:当请求缓存中不存在的key值,请求直接打到了db。
解决方案:初始化缓存或者查询缓存时,如果数据不存在,则缓存中设置空值。(疑问:初始化时,如何给不存在的key设置空值)
缓存更新策略(一致性)
1.Cache-Aside
1.先更新缓存在更新数据库。
存在问题:
-缓存更新成功,数据库更新失败,缓存中的值为旧值。
2.先更新数据库在更新缓存。
存在问题:
-key不存在时。线程1读取数据库旧值,线程2更新db,线程2将值放入缓存,线程1将值再次放入缓存,缓存中为旧值
-key不存在时。线程1更新db,线程2更新db,线程2将值放入缓存,线程1将值再次放入缓存,缓存中为旧值
image.png
3.先更新数据库,再失效缓存
存在问题:
-key失效,线程1读取db旧值,线程2更新db,线程2失效缓存,线程1将db旧值放入缓存。
image.png
产生条件
1.读操作读缓存失效
2.有个并发的写操作
3.读操作早于写操作进入数据库,晚于写操作更新缓存
2.Cache-As-SoR systemOfRecord 有cache组件统一更新缓存与db,客户端无感知。
1.Read-through
2.Write-through
3.Wtire-behind
缓存淘汰策略
1.LRU最近最少使用:map中记录访问次数
2.FIFO先进先出。
缓存过期策略
1.定期清理
2.查询时判断key是否过期
3.结合1+2
网友评论