MySQL和Redis的数据一致性
多线程环境下的涉及读写的缓存才会存在MySQL和Redis的数据不一致问题
先删除缓存再更新数据库再延时删除缓存
- 线程一删除缓存
- 线程一更新数据
- 线程二开始查数据
- 如果第二步线程一更新数据延时，那么线程二会重新从数据库加载数据，并将失效的数据设置到缓存
- 线程一更新完成数据库值之后，第二次延时删除缓存；延时删除是因为可能存在线程二查库返回失效数据还未将失效数据设置到缓存中时，线程一更新了数据库并立即删除了缓存，此时线程二会再一次将失效数据设置到缓存中，所以需要延时删除缓存，具体延时需要根据系统并发业务量判断
先更新数据库再删除缓存
- 线程一更新数据库
- 线程二开始读取缓存，在线程一还未删除缓存的时候，线程二一直读取失效数据
- 线程一删除缓存
双删机制还是会有概率导致MySQL和Redis的数据一致性，特别是当你第二次延时删除时间设置的不合适的时候，所以建议使用先更新数据库再删除缓存的方式，这样可以保证数据库的最终一致性。无论是哪一种删除机制都会存在缓存删除失败的情况，所以要引入缓存删除重试机制。下面是两种缓存删除重试机制
引入MQ缓存删除重试
- 更新数据库完成之后删除缓存
- 如果缓存删除失败，异步向MQ发送删除失败的缓存key
- 应用程序监听MQ，重试缓存删除，如果一直失败超过一定次数需要通知运维人员人工介入
引入MySQL的binlog订阅机制监听数据库数据变动处理缓存更新
和上面不一样的地方在于，我们使用的独立的Canal客户端订阅MySQL的binlog日志来执行缓存删除，而不是由主线程在更新数据库之后删除缓存，这在一定程度上实现了业务数据更新和缓存删除的解耦
