0. 缓存更新策略
| 内存淘汰 | 超时剔除 | 主动更新 | |
| 说明 | 利用redis的内存淘汰机制，当内存不足时自动淘汰部分数据，下次查询时更新缓存 | 给缓存数据添加过期时间，到期后删除缓存，下次查询再更新缓存 | 编写业务逻辑，自己控制在修改数据库时更新缓存 |
| 一致性 | 差 | 一般 | 好 |
| 维护成本 | 无 | 低 | 高 |
0.1 缓存主动更新策略
- 方案一：由缓存的调用者在更新数据库的时候同时更新缓存
- 方案二：将缓存和数据库整合为一个服务，由该服务来维护一致性。对外提供接口，调用者调用该服务提供的接口，无需关心缓存一致性问题
- 方案三：调用者只操作缓存，由其他线程异步将缓存数据持久化到数据库，保证最终一致性。
1. 数据同步策略
1.1 设置有效期
- 给缓存设置有效期
- 优点：简单方便
- 缺点：时效性差，缓存过期之前可能数据不一致
- 场景：适合更新频率低，时效性要求低的业务
1.2 同步双写
- 在修改数据库的同时，直接修改缓存
- 优点：时效性强，缓存与数据库强一致
- 缺点：有代码侵入，耦合度高
- 场景：对一致性、时效性要求较高的缓存数据
1.3 异步通知
- 修改数据库时发送事件通知，相关服务监听到通知后再修改缓存数据
- 优点：低耦合，可以同时通知多个缓存服务
- 缺点：时效性一般，可能存在中间不一致状态
- 场景：时效性要求一般，有多个服务需要同步
2. 保证缓存与数据库一致性的四个方案
- 先更新数据库，再更新缓存（有bug）
- 并发更新数据库场景下，会将脏数据刷新到缓存，不推荐
- 先更新缓存，再更新数据库（有bug）
- 缓存更新成功后，数据库更新失败，则会造成数据不一致性，而且也有并发问题，不推荐
- 先删除缓存，在更新数据库（有bug）
* 改进方法：先删缓存，再更新数据库，再删缓存
- 先更新数据库，再删除缓存（有bug）
* 更新数据库成功，但是删除缓存失败。
* 推荐这种，更新完数据库后删除缓存的速度是非常快的，所以在这个间隔内插入其他事务概率会比较低。
3. 先删除缓存，后更新数据库
3.1 可能出现的问题
- 请求A进行写操作，删除缓存
- 请求B查询发现缓存不存在
- 请求B去数据库查询得到旧值
- 请求B将旧值写入缓存
- 请求A将新值写入数据库
如果没有给缓存设置过期时间，则缓存数据永远都是脏数据
3.1 解决方式：延时双删
- 先淘汰缓存
- 再写数据库
- 休眠一秒后再次淘汰缓存
对于读写分离的数据库，主从同步之间也会有时间差，若此时来了两个请求，请求Ａ（更新操作）和请求Ｂ（查询操作），也会出现一些问题
- 请求Ａ更新操作，删除缓存
- 请求Ａ再主库进行更新操作，主库与从库进行数据同步操作
- 请求Ｂ查询操作，发现redis中没有数据
- 请求Ｂ去从库获取旧值数据
- 请求Ｂ更新缓存
- 主从同步完成
解决方法：如果对redis进行填充的查询数据库操作，那么强制将其指向主库进行查询
4. 先更新数据库，后删除缓存（推荐）
4.１可能出现的问题
- 更新数据库成功了，但是在删除缓存的阶段没有成功，则之后读取的缓存都是错误的
4.２解决方式一：异步实现之利用消息队列
- 请求A向服务端发送修改商品请求
- 相应的模块根据请求会对数据库对应内容进行更新，更新成功后会向MQ发送消息
1. 该消息通知缓存处理模块删除对应的缓存
- 缓存模块监听到有新的消息，会执行缓存删除逻辑
1. 利用消息队列的 手动提交机制 可以保证删除逻辑顺利完成
4.3 解决方式二：基于Canal的通知
- 商品服务完成数据库修改操作后，业务直接结束。没有任何代码侵入
- Canal监听mysql变化，当发现变化后，立即通知缓存服务
- 缓存服务接收到canal通知，删除缓存。
