面试官，如何保证缓存与数据库的数据一致性

0. 缓存更新策略

内存淘汰	超时剔除	主动更新
说明	利用redis的内存淘汰机制，当内存不足时自动淘汰部分数据，下次查询时更新缓存	给缓存数据添加过期时间，到期后删除缓存，下次查询再更新缓存	编写业务逻辑，自己控制在修改数据库时更新缓存
一致性	差	一般	好
维护成本	无	低	高

0.1 缓存主动更新策略

• 方案一：由缓存的调用者在更新数据库的时候同时更新缓存

• 方案二：将缓存和数据库整合为一个服务，由该服务来维护一致性。对外提供接口，调用者调用该服务提供的接口，无需关心缓存一致性问题

• 方案三：调用者只操作缓存，由其他线程异步将缓存数据持久化到数据库，保证最终一致性。

1. 数据同步策略

1.1 设置有效期

• 给缓存设置有效期
• 优点：简单方便
• 缺点：时效性差，缓存过期之前可能数据不一致
• 场景：适合更新频率低，时效性要求低的业务

1.2 同步双写

• 在修改数据库的同时，直接修改缓存
• 优点：时效性强，缓存与数据库强一致
• 缺点：有代码侵入，耦合度高
• 场景：对一致性、时效性要求较高的缓存数据

1.3 异步通知

• 修改数据库时发送事件通知，相关服务监听到通知后再修改缓存数据
• 优点：低耦合，可以同时通知多个缓存服务
• 缺点：时效性一般，可能存在中间不一致状态
• 场景：时效性要求一般，有多个服务需要同步

2. 保证缓存与数据库一致性的四个方案

• 先更新数据库，再更新缓存（有bug）
  • 并发更新数据库场景下，会将脏数据刷新到缓存，不推荐
• 先更新缓存，再更新数据库（有bug）
  • 缓存更新成功后，数据库更新失败，则会造成数据不一致性，而且也有并发问题，不推荐
• 先删除缓存，在更新数据库（有bug）
  * 改进方法：先删缓存，再更新数据库，再删缓存
• 先更新数据库，再删除缓存（有bug）
  * 更新数据库成功，但是删除缓存失败。
  * 推荐这种，更新完数据库后删除缓存的速度是非常快的，所以在这个间隔内插入其他事务概率会比较低。

总结：不推荐更新数据库的时候更新缓存。因为会有并发问题。推荐使用更新数据库时删除缓存，虽然也有问题。

3. 先删除缓存，后更新数据库

3.1 可能出现的问题

1. 请求A进行写操作，删除缓存
2. 请求B查询发现缓存不存在
3. 请求B去数据库查询得到旧值
4. 请求B将旧值写入缓存
5. 请求A将新值写入数据库

如果没有给缓存设置过期时间，则缓存数据永远都是脏数据

3.1 解决方式：延时双删

• 先淘汰缓存
• 再写数据库
• 休眠一秒后再次淘汰缓存

对于读写分离的数据库，主从同步之间也会有时间差，若此时来了两个请求，请求Ａ（更新操作）和请求Ｂ（查询操作），也会出现一些问题

1. 请求Ａ更新操作，删除缓存
2. 请求Ａ再主库进行更新操作，主库与从库进行数据同步操作
3. 请求Ｂ查询操作，发现redis中没有数据
4. 请求Ｂ去从库获取旧值数据
5. 请求Ｂ更新缓存
6. 主从同步完成

解决方法：如果对redis进行填充的查询数据库操作，那么强制将其指向主库进行查询

4. 先更新数据库，后删除缓存（推荐）

4.１可能出现的问题

• 更新数据库成功了，但是在删除缓存的阶段没有成功，则之后读取的缓存都是错误的

4.２解决方式一：异步实现之利用消息队列

1. 请求A向服务端发送修改商品请求
2. 相应的模块根据请求会对数据库对应内容进行更新，更新成功后会向MQ发送消息
   1. 该消息通知缓存处理模块删除对应的缓存
3. 缓存模块监听到有新的消息，会执行缓存删除逻辑
   1. 利用消息队列的 手动提交机制 可以保证删除逻辑顺利完成

4.3 解决方式二：基于Canal的通知

• 商品服务完成数据库修改操作后，业务直接结束。没有任何代码侵入
• Canal监听mysql变化，当发现变化后，立即通知缓存服务
• 缓存服务接收到canal通知，删除缓存。