引言
自Redis入门篇过后，已经好久没更Redis了，接下来应该从实战篇，原理篇，面试篇几个层次来展开，本篇主要是实战篇中的数据库缓存一致性问题，以问题形式展开，应对面试场景作答【melo称其为"手撕面答"】，尽量简短，某些部分可能不会进行详细介绍。
🎨本篇脑图速览
🎯为什么是删除缓存而不是更新缓存?
🎐懒加载
一种懒加载的思想，因为每次更改数据之后，不一定立马就有人来用。 若更新的次数远大于读取的次数，此时会频繁更新缓存，但一直没人使用，若缓存更新的成本很高的话，此时会非常浪费性能资源。
🎈并发更新的情况
ABBA 【A的操作过程中，穿插了B的完整过程】
- A更新数据库为1
- B更新数据库为2
- B更新缓存为2
- A更新缓存为1
最后导致数据库最终是2，但缓存是1，也就是B的缓存更新丢失了
🎯为什么要先更新数据库，再删除缓存
若先删除缓存，再更新数据库的话：
- A线程删除缓存
- B线程查询数据，缓存中没有了，会去计算数据库，设置缓存【此时计算出来的缓存是旧数据，是数据库更新之前的数据】
- A线程再更新数据库
接下来的查询，一直走的是缓存，也就是旧数据，这样就出现了数据库和缓存中数据不一致的情况
若先更新数据库，再删除缓存的话
- A线程更新数据库
- B线程查询数据，此时还未删除缓存，缓存中还有，得到的就是旧的缓存数据【此时就出现了数据库和缓存中数据不一致的情况】
- A线程再删除缓存
A读B写【先更后删可能会有数据不一致的情况，但很少见】
- A读取，发现缓存刚好过期了
- A查询出数据库的旧值，在设置缓存之前
- B更新数据库，并删除了缓存
- A用旧值，设置了缓存【缓存中是旧的数据，数据库是新的】
但由于缓存的写入要快于MySQL的写入，一般不可能在2跟4之间，穿插一个3操作【3还操作了数据库】
- 如果顺序是【2,4,3】的话，A设置了缓存之后也没关系，因为后续B还会再次删除缓存
- 之后的查询，发现缓存过期会去数据库中查询得到最新的数据
🎯🎈如何解决A读B写时先更后删的极端情况？
延时双删
- A读取，发现缓存失效了，此时去查询数据库【查出旧值】
- B更新数据库
- B设置新缓存
- A设置缓存为旧值
到这一步，如果之后的查询，查到的都会是旧的缓存，所以我们可以
- 延时500毫秒
延时500毫秒是为了让B能够更新完数据库，我们再次查询数据库才能获得最新的值，来设置缓存
- 删除缓存
🎯先删除缓存，后更新数据库如果也出现类似上边的问题怎么办？
假设一个场景：
- 请求A进行写操作，删除缓存
- 请求B查询发现缓存不存在
- 请求B去数据库查询得到旧值
- 请求B将旧值写入缓存
- 请求A将新值写入数据库
这时候缓存中的数据就是脏数据，如果缓存没有设置过期时间的话，就导致这个数据在下一次修改之前返回给用户的都是脏数据。
🎯从后者操作可能失败的角度来看，选择哪种策略更好一点？
先更新后删除缓存的话，后者失败，情况是这样的:
- A更新数据库，然后缓存没有删除成功
- B查询，直接走了缓存【旧数据】
这就出现了缓存跟数据库不一致的情况
先删除缓存后更新数据库的话，后者失败，情况是这样的：
- A删除缓存，然后没能更新数据库
- B查询，发现缓存没有，则去查询数据库，设置到缓存里边
此时并不会出现缓存跟数据库不一致的情况，因为A还没来得及更新，这样数据库跟缓存中，一直都是旧的数据，但至少不会出现数据不一致的问题
- 所以如果从这个角度来看的话，先删除缓存，后更新数据库才是更优解。
🎯🎈如何解决后者失败的情况呢？
使用消息队列重试
- 请求 A 先对数据库进行更新操作，同时吧
- 在对 Redis 进行删除操作的时候发现报错，删除失败
- 此时将Redis 的 key 作为消息体发送到消息队列中
- 系统接收到消息队列发送的消息后再次对 Redis 进行删除操作
但是这个方案会有一个缺点就是会对业务代码造成大量的侵入，深深的耦合在一起。
有没有必要更新成功后就投递到mq呢？而不是等到redis删除失败了再投递到mq
如果考虑Java项目进程在更新数据库之后就宕机了的话，那无论哪种都没法避免缓存删除的失败 如果硬抠的话，更新成功后，到删除redis还有一段间隙，这个间隙先投递到mq，会更有保障一点，但相应的编码规则也更麻烦了点
- 更新数据库成功，投递到mq表示要删除 某个key
- 业务继续执行，删除redis：
- 删除成功的话，需要删除掉mq里边的消息，防止重复消费
- 删除失败的话，就需要消费者拉取mq，再次删除缓存，实现重试机制，当然，如果重试超过的一定次数，还是没有成功，我们就需要向业务层发送报错信息了。后续的处理可能就先丢到死信队列里边了。
可以发现编码确实麻烦了些，因为要考虑重复消费的问题。那么如何解决呢？Java崩了，咱下游还有 mysql 和 mq 没崩呢！也就因此引出了下文的订阅binlog日志的方法
订阅binlog日志
原理：更新数据库成功，就会产生一条变更日志，记录在 binlog 里。
于是我们就可以通过订阅 binlog 日志，拿到具体要操作的数据，然后再执行缓存删除，阿里巴巴开源的 Canal 中间件就是基于这个实现的。
具体流程：
- canal模拟mysql slave的交互协议，伪装自己为mysql slave，向mysql master发送dump协议；
- mysql master收到dump请求，开始推送binary log给slave(也就是canal)；
- canal解析binary log对象(原始为byte流)；
- canal将解析后的对象，根据业务场景，分发到比如 MySQL 、RocketMQ 或者 ES 中。
总结
