Cache aside
系统常用方式旁路缓存
- 查询缓存服务存在则返回,不存在查询数据库
- 数据库存在更新缓存,返回数据,不存在更新缓存为null(有效期),防止缓存穿透
- 更新数据库后,更新\删除缓存
应用场景:
- 适用于查询频繁的业务场景(配置信息,登录用户信息...)
优点:缓存未命中查询数据库,属于懒加载模式(Lazy Loading)
缺点:
1.未命中时,操作流程复杂,查缓存,查数据库,更新缓存
2.数据更新频繁时,缓存更新频繁,缓存作用降低
3.容易导致数据不一致,产生脏数据
Cache aside 缓存4种更新方式
第一种先更新缓存,再更新数据库;
第二种先删除缓存,再更新数据库;
第三种先更新数据库;在更新缓存;
第四种先更新数据库;在删除缓存;
四种更新缓存导致不一致概率如下:
(缓存更新延迟 远低于 数据库更新)
第一种 > 第二种 > 第三种 > 第四种
建议应用系统使用第三种,第四种作为缓存更新方式,如果对数据一致性要求比较严格,
建议采用第4种(优化更新数据库后,立马删除缓存,然后再停顿几秒在删除一次)
Cache aside 缓存模式下 缓存击穿,缓存穿透,缓存雪崩解决
缓存击穿:
查询缓存没有,数据库有;大量并发查询情况下,导致数据库压力增加,导致系统不可用
解决方案:
缓存预热;查询数据库时对key加互斥锁;缓存不设置有效期(不建议)
缓存穿透:
查询缓存没有,数据库也没有;大量并发情况下,导致数据库压力增加,导致系统不可用
解决方案:
对查询数据校验;布隆过滤(布谷鸟过滤);查询数据库时对key加互斥锁,数据库不存在时,更新缓存为null并设置几秒的有效期;
缓存雪崩
查询缓存时,出现大量的数据过期,查询大量打到数据库,导致数据库压力增加,导致系统不可用
解决方案:
给缓存有效期增加一个随机的时间;热点数据不设置有效期;热点数据分散不同服务器
Read/Write through
缓存使用说明
将缓存作为主要的数据源,而数据库对于应用程序是透明的,读取、更新数据库任务都交给缓存来代理
应用场景
查询多,更新少,数据一致性高场景
优点:数据一致性高,查询快
缺点:对于频繁写入的场景,造成延迟,性能降低
Write behind
缓存使用方式
将缓存作为可靠的数据源,每次都只写入缓存;数据库操作采用异步的方式
应用场景
写多,读少的应用场景(库存,预下单)
优点:异步更新数据库,降低数据库压力;抗并发能力强,完全依赖缓存
缺点:容易数据不一致,数据缺失风险