MySQL和Redis的数据一致性

一、保证数据一致性的四个方案

 

• 先更新数据库，再更新缓存（有bug）
  • 并发更新数据库场景下，会将脏数据刷新到缓存，不推荐

    • 同时有请求A和请求B进行更新操作，那么会出现：

    • 线程A更新了数据库；

    • 线程B更新了数据库；

    • 线程B更新了缓存；

    • 线程A更新了缓存；

• 先更新缓存，再更新数据库（有bug）
  • 缓存更新成功后，数据库更新失败，则会造成数据不一致性，而且也有并发问题，不推荐
• 先删除缓存，再更新数据库（有bug）
  • 改进方法：先删缓存，再更新数据库，再删缓存
• 先更新数据库，再删除缓存（有bug）
  • 更新数据库成功，但是删除缓存失败。

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

二、 先删除缓存，后更新数据库

2.1 可能出现的问题

1. 请求A进行写操作，删除缓存
2. 请求B查询发现缓存不存在
3. 请求B去数据库查询得到旧值
4. 请求B将旧值写入缓存
5. 请求A将新值写入数据库
6. 如果没有给缓存设置过期时间，则缓存数据永远都是脏数据

2.2 解决方式：延时双删

• 先淘汰缓存
• 再写数据库
• 休眠一秒后再次淘汰缓存，可以将1秒内所造成的缓存脏数据，再次删除！

2.3 主从同步存在的问题

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

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

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

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

3.１可能出现的问题

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

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

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

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

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