文章目录
- 1、缓存更新策略
- 1.1、内存淘汰
- 1.2、超时剔除
- 1.3、主动更新
- 2、业务场景：
- 3、主动更新在企业中业务实现有三种方式
- 3.1、Cache Aside Pattern
- 3.1.1、操作缓存和数据库时有三个问题需要考虑：
- 3.1.1.1、删除缓存还是更新缓存？
- 3.1.1.2、如何保证缓存与数据库的操作的同时成功或失败？
- 3.1.1.3、先操作缓存还是先操作数据库？
- 3.2、Read/Write Through Pattern
- 3.3、Write Behind Caching Pattern
- 4、缓存更新策略的最佳实践方案：
- 5、读操作
- 6、写操作：
1、缓存更新策略
1.1、内存淘汰
说明：不用自己维护，利用Redis的内存淘汰机制，当内存不足时自动淘汰部分数据。下次查询时更新缓存。
一致性：差
维护成本：无
1.2、超时剔除
说明：给缓存数据添加TTL（Time To Live）时间，到期后自动删除缓存。下次查询时更新缓存。
一致性：一般
维护成本：低
1.3、主动更新
编写业务逻辑，在修改数据库的同时，更新缓存
一致性：好
维护成本：高
2、业务场景：
低一致性需求：使用内存淘汰机制。例如店铺类型的查询缓存高一致性需求：主动更新，并以超时剔除作为兜底方案。例如店铺详情查询的缓存
3、主动更新在企业中业务实现有三种方式
3.1、Cache Aside Pattern
企业用的最多
由缓存的调用者，在更新数据库的同时更新缓存
3.1.1、操作缓存和数据库时有三个问题需要考虑：
3.1.1.1、删除缓存还是更新缓存？
- 更新缓存：每次更新数据库都更新缓存，无效写操作较多
删除缓存：更新数据库时让缓存失效，查询时再更新缓存，一般会选择删除缓存的这个方案
3.1.1.2、如何保证缓存与数据库的操作的同时成功或失败？
- 单体系统：将缓存与数据库操作放在一个事务
- 分布式系统：利用TCC等分布式事务方案
3.1.1.3、先操作缓存还是先操作数据库？
- 先删除缓存，再操作数据库
- 先操作数据库，再删除缓存，胜出
3.2、Read/Write Through Pattern
缓存与数据库整合为一个服务，由服务来维护一致性。调用者调用该服务，无需关心缓存一致性问题。
3.3、Write Behind Caching Pattern
调用者只操作缓存，由其它线程异步的将缓存数据持久化到数据库，保证最终一致。
4、缓存更新策略的最佳实践方案：
- 低一致性需求：使用Redis自带的内存淘汰机制
- 高一致性需求：主动更新，并以超时剔除作为兜底方案
5、读操作
- 缓存命中则直接返回
- 缓存未命中则查询数据库，并写入缓存，设定超时时间
6、写操作：
- 先写数据库，然后再删除缓存
- 要确保数据库与缓存操作的原子性
