如何保证缓存一致性

旁路缓存

在实际业务中，我们经常采用的一种缓存策略如下：

缓存-数据库读流程

用户发起查询请求
业务服务首先根据关键参数作为key查询缓存
如果数据在缓存中存在cache hit，则直接返回缓存中查询结果。
如果数据不在缓存中cache miss，则进行数据库查询操作，将结果缓存并返回查询结果。

缓存-数据库写流程

用户发起请求，需要写数据。
业务服务在完成逻辑处理后，开始更新数据库。
数据库更新完成后根据key删除缓存数据（or 更新？）

上述这种数据缓存策略被称为旁路缓存策略（Cache-Aside Strategy），其核心思想是：只有当有应用来请求时，才将对应的对象进行缓存。并且这种策略适用于读取频繁但是写入或更新不频繁的场景，即数据一旦写入后主要用于查询展示，基本不会更新。

在Cache-Aside策略下，当出现数据写入/更新请求处理中有这样两个问题需要选择：

对缓存中的老数据进行更新还是删除？
在处理时先更新数据库还是先处理缓存

更新 OR 删除

假设我们选择的是缓存更新，下面来分析在实际多请求并发的情况下

同时有请求A和B对数据进行更新操作；
在各自的业务线程A和B中对请求进行处理；
线程A更新数据库为90，线程B更新数据库为80;
因线程A、B并发执行，B优先更新了缓存，随后线程A执行缓存更新，导致数据库中值为80，缓存中数据为90，出现数据库和缓存的不一致。

基于这个场景来看，确实选择删除缓存可以避免出现类似问题，最多会出现cache miss，触发从数据库查询加载。

除此之外，我们从「缓存利用率」的角度来评估这个方案，也是不太推荐的，很多时候，在复杂点的缓存场景，缓存不单单是数据库中直接取出来的值。

比如可能更新了某个表的一个字段，然后其对应的缓存，是需要查询另外两个表的数据并进行运算，才能计算出缓存最新的值的。

另外更新缓存的代价有时候是很高的。是不是说，每次修改数据库的时候，都一定要将其对应的缓存更新一份？也许有的场景是这样，但是对于比较复杂的缓存数据计算的场景，就不是这样了。如果你频繁修改一个缓存涉及的多个表，缓存也频繁更新。但是问题在于，这个缓存到底会不会被频繁访问到？

举个栗子，一个缓存涉及的表的字段，在 1 分钟内就修改了 20 次，或者是 100 次，那么缓存更新 20 次、100 次；但是这个缓存在 1 分钟内只被读取了 1 次，有大量的冷数据。实际上，如果你只是删除缓存的话，那么在 1 分钟内，这个缓存不过就重新计算一次而已，开销大幅度降低。用到缓存才去算缓存。

其实删除缓存，而不是更新缓存，就是一个 lazy 计算的思想，不要每次都重新做复杂的计算，不管它会不会用到，而是让它到需要被使用的时候再重新计算。像 mybatis，hibernate，都有懒加载思想。查询一个部门，部门带了一个员工的 list，没有必要说每次查询部门，都里面的 1000 个员工的数据也同时查出来啊。80% 的情况，查这个部门，就只是要访问这个部门的信息就可以了。先查部门，同时要访问里面的员工，那么这个时候只有在你要访问里面的员工的时候，才会去数据库里面查询 1000 个员工。

先数据库 OR 先缓存

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

如果有 2 个线程要并发「读写」数据，可能会发生以下场景：

线程 A 要更新 X = 2（原值 X = 1）
线程 A 先删除缓存
线程 B 读缓存，发现不存在，从数据库中读取到旧值（X = 1）
线程 A 将新值写入数据库（X = 2）
线程 B 将旧值写入缓存（X = 1）

最终 X 的值在缓存中是 1（旧值），在数据库中是 2（新值），发生不一致。

可见，先删除缓存，后更新数据库，当发生「读+写」并发时，还是存在数据不一致的情况。

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

依旧是 2 个线程并发「读写」数据：

缓存中 X 不存在（数据库 X = 1）
线程 A 读取数据库，得到旧值（X = 1）
线程 B 更新数据库（X = 2)
线程 B 删除缓存
线程 A 将旧值写入缓存（X = 1）

最终 X 的值在缓存中是 1（旧值），在数据库中是 2（新值），也发生不一致。

这种情况「理论」来说是可能发生的，但实际真的有可能发生吗？

其实概率「很低」，这是因为它必须满足 3 个条件：

缓存刚好已失效
读请求 + 写请求并发
更新数据库 + 删除缓存的时间（步骤 3-4），要比读数据库 + 写缓存时间短（步骤 2 和 5）

仔细想一下，条件 3 发生的概率其实是非常低的。

因为写数据库一般会先「加锁」，所以写数据库，通常是要比读数据库的时间更长的。

这么来看，「先更新数据库 + 再删除缓存」的方案，是可以保证数据一致性的。

所以，我们应该采用这种方案，来操作数据库和缓存。

第二步失败补偿

无论是更新缓存还是删除缓存，只要第二步发生失败，或者遇到了上述理论中的极端情况,那么就会导致数据库和缓存不一致。

保证第二步成功执行，就是解决问题的关键。

想一下，程序在执行过程中发生异常，最简单的解决办法是什么？

答案是：重试。

是的，其实这里我们也可以这样做。

无论是先操作缓存，还是先操作数据库，但凡后者执行失败了，我们就可以发起重试，尽可能地去做「补偿」。

那这是不是意味着，只要执行失败，我们「无脑重试」就可以了呢？

答案是否定的。现实情况往往没有想的这么简单，失败后立即重试的问题在于：

立即重试很大概率「还会失败」
「重试次数」设置多少才合理？
重试会一直「占用」这个线程资源，无法服务其它客户端请求

看到了么，虽然我们想通过重试的方式解决问题，但这种「同步」重试的方案依旧不严谨。

那更好的方案应该怎么做？

答案是：异步重试。什么是异步重试？

消息队列

为了保证缓存删除成功，需要在缓存失败时增加重试机制。可以借助消息队列，将删除失败的数据进行异步重试。

用户发起请求，需要写入更新数据
业务服务首先进行数据库更新操作
然后业务服务进行缓存删除，因某些原因导致失败
将删除失败缓存key进入消息队列
消费消息队列中的消息，获取需要重试的缓存key
重试缓存删除操作

或者更直接的做法，为了避免第二步执行失败，我们可以把操作缓存这一步，直接放到消息队列中，由消费者来操作缓存。

到这里你可能会问，写消息队列也有可能会失败啊？而且，引入消息队列，这又增加了更多的维护成本，这样做值得吗？

这个问题很好，但我们思考这样一个问题：如果在执行失败的线程中一直重试，还没等执行成功，此时如果项目「重启」了，那这次重试请求也就「丢失」了，那这条数据就一直不一致了。

所以，这里我们必须把重试消息或第二步操作放到另一个「服务」中，这个服务用「消息队列」最为合适。这是因为消息队列的特性，正好符合我们的需求：

消息队列保证可靠性：写到队列中的消息，成功消费之前不会丢失（重启项目也不担心）
消息队列保证消息成功投递：下游从队列拉取消息，成功消费后才会删除消息，否则还会继续投递消息给消费者（符合我们重试的需求）

至于写队列失败和消息队列的维护成本问题：

写队列失败：操作缓存和写消息队列，「同时失败」的概率其实是很小的
维护成本：我们项目中一般都会用到消息队列，维护成本并没有新增很多

所以，引入消息队列来解决这个问题，是比较合适的。这时架构模型就变成了这样：

方案分析

该方案虽然将重试逻辑拆除独立执行，但需要在正常业务逻辑中加入删除失败处理代码，侵入性很强。下面看借助MySQL BinLog实现缓存删除的方案

订阅binlog

那如果你确实不想在应用中去写消息队列，是否有更简单的方案，同时又可以保证一致性呢？

方案还是有的，这就是近几年比较流行的解决方案：订阅数据库变更日志，再操作缓存。

具体来讲就是，我们的业务应用在修改数据时，「只需」修改数据库，无需操作缓存。

那什么时候操作缓存呢？这就和数据库的「变更日志」有关了。

拿 MySQL 举例，当一条数据发生修改时，MySQL 就会产生一条变更日志（Binlog），我们可以订阅这个日志，拿到具体操作的数据，然后再根据这条数据，去删除对应的缓存。

订阅变更日志，目前也有了比较成熟的开源中间件，例如阿里的 canal. 当然，与此同时，我们需要投入精力去维护 canal 的高可用和稳定性。

如果你有留意观察很多数据库的特性，就会发现其实很多数据库都逐渐开始提供「订阅变更日志」的功能了，相信不远的将来，我们就不用通过中间件来拉取日志，自己写程序就可以订阅变更日志了，这样可以进一步简化流程。

方案流程:

用户发起请求，需要写入更新数据
业务服务进行数据库更新操作完成业务请求
数据库操作写入BinLog日志
通过中间件订阅数据库BinLog日志（如：canel），获取需要更新缓存的key和数据
根据解析结果进行缓存删除，如果删除失败则放入消息队列
消费消息队列中的消息，获取需要重试的缓存key
重试缓存删除操作

使用这种方案的优点在于：

无需考虑写消息队列失败情况：只要写 MySQL 成功，Binlog 肯定会有
自动投递到下游队列：canal 自动把数据库变更日志「投递」给下游的消息队列

主从库延迟放大数据不一致

在「读写分离 + 主从复制延迟」情况下，如果使用「先更新数据库，再删除缓存」方案，其实也发生不一致：

线程 A 更新主库 X = 2（原值 X = 1）
线程 A 删除缓存
线程 B 查询缓存，没有命中，查询「从库」得到旧值（从库 X = 1）
从库「同步」完成（主从库 X = 2）
线程 B 将「旧值」写入缓存（X = 1）
最终 X 的值在缓存中是 1（旧值），在主从库中是 2（新值），也发生不一致。

看到了么？这 2 个问题的核心在于：缓存都被回种了「旧值」。

那怎么解决这类问题呢？

最有效的办法就是，把缓存再一次删掉,也就是延时双删.

延时双删

从名字可以看出方案的本质在于在延迟一定时间后，再进行一次缓存的删除，来解决并发情况下缓存到老数据的问题，即使先操作缓存后操作数据库也可以保证最终数据的一致。

方案流程

用户发起请求，需要写入更新数据
业务服务首先进行删除缓存
然后业务服务进行数据库的更新操作
在延迟一定时间T后，再执行一次缓存删除(可以生成一条「延时消息」，写到消息队列中，消费者延时「删除」缓存)

但问题来了，这个「延迟删除」缓存，延迟时间到底设置要多久呢？

问题1：延迟时间要大于「主从复制」的延迟时间
问题2：延迟时间要大于线程 B 读取数据库 + 写入缓存的时间

但是，这个时间在分布式和高并发场景下，其实是很难评估的。

很多时候，我们都是凭借经验大致估算这个延迟时间，例如延迟 1-5s，只能尽可能地降低不一致的概率。

所以你看，采用这种方案，也只是尽可能保证一致性而已，极端情况下，还是有可能发生不一致。

SETEX与SETNX

Storage 和 Cache 同步更新容易出现数据不一致。

模拟 MySQL Slave 做数据复制，再把消息投递到 Kafka，保证至少一次消费：

同步操作DB；
同步操作Cache；
利用Job消费消息，重新补偿一次缓存操作

保证时效性和一致性。

Cache Aside 模型中，读缓存 Miss 的回填操作，和修改数据同步更新缓存，包括消息队列的异步补偿缓存，都无法满足 “Happens Before”，会存在相互覆盖的情况。

读/写同时操作：

读操作，读缓存，缓存 MISS
读操作，读 DB，读取到数据
写操作，更新 DB 数据
写操作 SET/DELETE Cache（可 Job 异步操作）
读操作，SET操作数据回写缓存（可 Job 异步操作）

这种交互下，由于4和5操作步骤都是设置缓存，导致写入的值互相覆盖；并且操作的顺序性不确定，从而导致 cache 存在脏缓存的情况。