缓存一致性

1.两次更新

• 先更新数据库，再更新缓存；
• 先更新缓存，再更新数据库；

出现不一致问题场景：

先更新数据库，再更新缓存；

先更新缓存，再更新数据库；

两次更新的适用场景：

        如果我们的业务对缓存命中率(一定要用到缓存)有很高的要求，我们可以采用「更新数据库 + 更新缓存」的方案，因为更新缓存并不会出现缓存未命中的情况。

 解决缓存不一致的办法

• 在更新缓存前先加个分布式锁，保证同一时间只运行一个请求更新缓存，就会不会产生并发问题了，当然引入了锁后，对于写入的性能就会带来影响。
• 在更新完缓存时，给缓存加上较短的过期时间，这样即时出现缓存不一致的情况，缓存的数据也会很快过期，对业务还是能接受的。

2.更新+删除策略

2.1 先删除缓存再更新数据库

出现问题的场景

请求A更新 请求B读取

解决办法

延迟双删：

        请求A先删除缓存然后再更新数据库，再给A加个睡眠时间，主要是为了确保其他请求完成读操作写入的缓存，然后请求 A 睡眠完，再删除缓存。

        所以，请求 A 的睡眠时间就需要大于请求 B 「从数据库读取数据 + 写入缓存」的时间。

但是具体睡眠多久其实是个玄学，很难评估出来，所以这个方案也只是尽可能保证一致性而已，极端情况下，依然也会出现缓存不一致的现象。

因此，还是比较建议用「先更新数据库，再删除缓存」的方案。

2.2 先更新数据库再删除缓存

请求A读取 请求B更新

上图是可能出现不一致的场景，但是在实际中，这个问题出现的概率并不高。因为缓存的写入通常要远远快于数据库的写入。

出现问题的场景:

     「先更新数据库， 再删除缓存」其实是两个操作，在删除缓存（第二个操作）的时候可能会失败，导致缓存中的数据是旧值，而数据库是最新值。

确保删除成功的办法

消息队列重试机制

        我们可以引入消息队列，将第二个操作（删除缓存）要操作的数据加入到消息队列，由消费者来操作数据。

• 如果应用删除缓存失败，可以从消息队列中重新读取数据，然后再次删除缓存，这个就是重试机制。当然，如果重试超过的一定次数，还是没有成功，我们就需要向业务层发送报错信息了。
• 如果删除缓存成功，就要把数据从消息队列中移除，避免重复操作，否则就继续重试。

缺点是，对代码入侵性比较强，因为需要改造原本业务的代码。

订阅 MySQL binlog，再操作缓存

        如果是MySQL、Redis缓存同步场景，为了保证成功率，可以用一个消费服务订阅MySQL binlog 日志，拿到具体要操作的数据，然后再向Redis执行缓存删除操作。

更具体的说法：

        可以通过订阅 binlog 日志，拿到具体要操作的数据，然后再执行缓存删除，阿里巴巴开源的 Canal 中间件就是基于这个实现的。

        Canal 模拟 MySQL 主从复制的交互协议，把自己伪装成一个 MySQL 的从节点，向 MySQL 主节点发送 dump 请求，MySQL 收到请求后，就会开始推送 Binlog 给 Canal，Canal 解析 Binlog 字节流之后，将binlog日志采集发送到MQ队列里面，然后编写一个简单的缓存删除消息者订阅binlog日志，根据更新log删除缓存，并且通过ACK机制确认处理这条更新log，保证数据缓存一致性。

八股总结