如何保证缓存和数据库一致性？

很多人对这个问题依然有很多疑惑：

• 到底是更新缓存还是删除缓存？
• 选择先更新数据库再删除缓存，还是先删除缓存再更新数据库？
• 为什么要引入消息队列保证一致性？
• 延迟双删会产生哪些问题？到底要不要用？如何用？

引入缓存提高性能

我们从最简单的场景开始说起。

如果项目业务处于起步阶段，流量非常少，读写请求直接操作数据库即可，此时你的架构模型是这样：

但是随着业务量的增长，你的项目请求量越来越大，如果每次都从DB中读取，那必然会产生性能问题。

通常这个阶段会引入【缓存】来提高读写性能，架构模型就会发生转变：

目前主流的缓存中间件，当属Redis，不仅性能高，还支持多种数据类型，能更好的满足我们的业务需求。

但是加入缓存之后，就会面临这样的一个问题：之前数据只存放在数据库中，从数据库读取，现在要放到缓存中读取，具体要存储什么呢？

最简单直接的方案就是【全量数据刷到缓存中】

• 数据库的数据，全量刷到缓存中（不设置失效时间）
• 写请求只更新数据库，不更新缓存
• 启动一个定时任务，定时将数据库中的数据，同步更新到缓存中
  
  这个方案的有点不必多说，所有请求都全部【命中】缓存，不需要经过数据库，性能非常高。

但是缺点也很明显，主要体现以下两点。

• 缓存利用率低，不是所有的缓存都是热点，不经常访问的数据长期存放在缓存中，会导致资源浪费
• 数据不一致，因为采取的是【定时刷新缓存】的机制，导致缓存数据与数据库数据不一致（取决于定时刷新的频率）

所以，这个方案适用于【体量小】的业务，对数据一致性要求不高的业务场景。

那么，针对体量很大的业务场景，怎么解决这两个问题呢？

缓存利用率和一致性问题

先来看第一个问题，如何提高缓存利用率的问题。

说到这，想要缓存利用率【最大化】，我们很容易能想到的方案是，缓存中只保留最近访问或经常访问的【热点数据】。

我们可以这样优化

• 写请求依旧只写数据库
• 读请求先读缓存，如果缓存不在，则从数据库读取，并重建缓存
• 同时，写入缓存中的数据，都设置失效时间（错开失效时间）
  

这样一来，缓存中不经常访问的key，随着时间的推移，都会时间【过期】淘汰掉，最终缓存中保留的，都是热点数据，从而缓存的利用率得以最大化。

再看数据一致性的问题。

想要保证缓存和数据库【实时】一致，那就不能再使用定时任务刷新缓存的方案。

所以，当数据发生更新时，我们不仅要操作更新数据库，还要一并操作缓存。具体的操作就是修改一条数据时，不仅要更新数据库，连带着缓存一起更新，或者删除相应的缓存，再次访问时是会查询数据库后进行重建缓存。

但数据库和缓存都更新，有存在先后的问题，那对应的方案就有2个：

1.先更新缓存，后更新数据库
2.先更新数据库，后更新缓存

哪一个方案更好呢？

这里先不考虑并发的问题，正常情况下，无论谁先谁后，都可以让两者保持一致，但现在我们需要重点考虑【异常】情况。

因为操作是分两步，那么就有可能在【第一个成功，第二个失败】的情况发生。

1、先更新缓存，后更新数据库

如果更新成功了，但数据库更新失败，那么此时缓存中是最新值，但是数据库中是【旧值】

虽然此时请求可以命中缓存，拿到正确的值，但是一旦缓失，就会从数据库中读取到【旧值】，重建缓存也是这个旧值。

这时用户就会发现自己之前的修改【又变回去了】，对业务造成影响。

2、先更新数据库，后更新缓存

如果更新数据库成功了，但是缓存更新失败了，那么此时数据库中是最新的值，缓存中是【旧值】。

之后的读请求都读到的是旧数据，只有当缓存【失效】后，才能从数据库中得到正确的值。

这时用户就会发现，自己刚刚修改了数据，但发现不生效，过一段时间后，数据才变更过来，对业务也会有影响。

可见，无论是谁先谁后，但凡后者发生异常，就会对业务造成影响。那么怎样解决这个问题呢？

我们继续分析，除了操作失败问题，还有什么场景会影响数据一致性？

这里我们还要重点关注：并发问题

并发引起的一致性问题

假如我们采用【先更新数据库，在更新缓存】的方案，并且两步都可以成功执行的前提下，如果存在并发，会是什么情况呢？

有线程A 和线程 B 两个线程，需要更新【同一条数据】，会发生这样的场景：

1. 线程A 更新数据库（X=1）
2. 线程B 更新数据库（X=2）
3. 线程B 更新缓存（X=2）
4. 线程A 更新缓存（X=1）

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

也就是说，A虽然先于B发生，但B操作数据库和缓存的时间，却要比B的时间更短，执行时序发生【错乱】，最终导致这条数据结果不符合预期的。

同样的，采用【新更新缓存，在更新数据库】的方案，也会有类似的问题。

除此之外，我们从【缓存利用率】的角度来评估这个方案，也是不太难推敲的。

这是因为每次数据发生变更，都更新缓存，但是缓存中的数据不一定会被马上读取，这就会导致缓存中存放了很多不常访问的数据，浪费缓存资源。

而且很多情况下，写到缓存中的值，并不是与数据库中的值一一对应的，很可能先查数据库，经过一系列计算得出的值，才把这个值写到缓存中。

由此可见，这种【更新数据库+更新缓存】的方案，不仅缓存利用率不到，还会造成服务器资源和性能的浪费。

所以此时我们需要考虑另外一种方案：删除缓存

删除缓存可以保证一致性吗？

删除缓存对应的方案也有 2 种：

1. 先删除缓存，再更新数据库
2. 先更新数据库，再删除缓存

经过前面的分析我们可以知道，但凡【第二步】操作失败，都会导致数据不一致。

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

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

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

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

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

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

依旧是两个线程【并发读写】数据 ：

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

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

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

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

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

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

因为写数据库一般会先【加锁】，所以写数据库，通常是要比读数据库的时间更长的。
这么看来，【先更新数据库 + 再删除缓存】的方案，是可以保证数据一致性的。

所以，我们应该采用这种方案（【先更新数据库 + 再删除缓存】）来操作数据库和缓存。

嗯，解决了并发问题，我们继续来看前面遗留的，第二步执行失败，导致数据不一致的问题

如何保证两步都执行？

通过前面的分析，无论是更新缓存还是删除缓存，只要第二步出现失败，就会导致数据库和缓存的结果不一致。

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

程序在执行过程中发生异常，最简单的解决办法是：重试

但这并不意味着，只要执行失败（出现异常），我们重试就可以了。

实际情况往往没那么简单，失败后立即重试的问题在于：

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

由此可见了，虽然我们想通过重试的方式解决问题，但是这种【同步重试】的方案依旧不严谨。

那么另一种更好的方案是：异步重试

异步重试，其实就是把重试请求放到【消息队列】中，然后由专门的消费者来进行重试，直到成功。

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

这里你可能会疑惑，写队列也有可能会失败，而且引入消息队列，这又会增加了更多的维护成本，增加项目复杂度，这样做是否值得？

这是个好问题，抛开项目复杂度，我们思考这样一个问题：如果在执行失败的线程中一直重试，还没等执行成功，此时如果项目重启了，那么重试的请求就丢失了，这一条数据就不一致了。

所以，我们必须将重试或者第二步骤放到另一个服务中，这个服务用【消息队列】最为合适，因为消息队列的特性，可以满足我们的需求：

• 消息队列可靠性：写到队列中的消息，成功消费之前不会丢失（重启也不担心）
• 消息队列保证消息成功投递：消费者从队列拉取消息，成功消费后才会删除（message_id）,否则还会继续投递消息给消费者（符合重试场景）

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

• 写入队列失败：操作缓存和写消息队列，同时失败的概率是非常小的
• 维护成本：达到一定量级，我们项目中都会使用消息队列，维护成本并没有增加很多

所以，引入消息队列来解决第二个步骤失败重试的问题，是比较合适的，这时候的架构就变成了这样：

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

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

具体来说就是，业务在修改数据时，只需修改数据库，无需操作缓存。

那什么时候操作缓存呢，这个就与数据库的【变更日志】有关

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

订阅变更日志，目前也有比较成熟的开源中间件，例如阿里的canal，使用这种方案的有点在于：

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

当然，于此同时，我们需要投入经历去维护canal的高可用和稳定性。

根据数据库的特性，很多数据库都逐渐开始提供【订阅变更日志】的功能，到时候就不用通过中间件来拉取日志，可以自己写程序订阅变更日志，进一步简化流程。

到这里，可以得出的结论，想要保证数据和缓存一致性，推荐采用【先更新数据库，再删除缓存】的方案，并且配合【消息队列】或【订阅变更日志】的方式来做

主从延迟和延迟双删问题

到这里，还有两个问题

第一个问题：前面【先删缓存，再更新数据库】，导致不一致的问题。
第二个问题：关于【读写分离 + 主从复制延迟】情况下，缓存和数据库一致性的问题。

那么，如何解决这类的问题呢？

最有效的办法就是，将缓存删掉

但是不能立即删，而是需要【延迟删】，这就是：缓存延迟双删策略

按照这个延迟双删策略，这两个问题解决方案如下：

解决第一个问题：在线程A 删除缓存、更新完数据库之后，先【休眠一会】，再【删除】一次缓存。
解决第二个问题：可以生成一条【延迟消息】，写到消息队列中，消费者延迟删除缓存

这两个方案的目的都是为了将缓存清掉，这样一来，下次就可以从数据库读取到最新值，写入缓存。

但是相应的，这个延迟删除，延迟时间设置多久才合适？

• 问题1：延迟时间要大于主从复制的延迟时间
• 问题2：延迟时间要大于第二个线程读取数据+写入缓存的时间

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

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

所以，极端的情况下，还是会有可能发生不一致。

可以做到强一致性吗？

如果想让缓存和数据到达到【强一致性】，其实很难做到的。

这往往要 牺牲性能

一旦我们使用缓存，就必然会出现一致性的问题，性能与一致性，无法做到保持平衡。势必会向一方倾斜。

如果非要达到强一致性，那就必须在完成更新操作之前，不能有任何请求处理，这在实际高并发的场景中是不可取的。

虽然也可以使用【分布式锁】来实现，但是加锁与释放的过程，也会降低其性能，有时候甚至会超过引入缓存带来的性能提升。

所以，我们既然决定使用缓存，就必须容忍【一致性】问题，我们只能尽可能地降低出现问题的概率

总结

• 将要提高应用性能，可以引入缓存来解决
• 引入缓存后，就要考虑缓存和数据库一致性的问题，建议，更新数据库，删除缓存
• 更新数据库 + 删除缓存的方案，在并发场景下无法保证缓存与数据保持一致性，且存在缓存资源浪费和机器性能浪费的情况。
• 并发场景下的延迟双删策略，这个延迟时间很难评估，所以推荐【先更新数据库，再删除缓存】的方案
• 在【先更新数据库，再删除缓存】的方案下，为了保证两步都能执行成功，需要配合【消息队列】或【订阅变更日志】的方案来做，其本质是通过重试的方式保证数据一致性。
• 在【先更新数据库，再删除缓存】方案下，【读写分离 + 主从延迟】也会导致缓存和数据库不一致，解次问题的方案是【延迟双删】，凭借经验发送【延迟消息】到队列中，延迟删除缓存，同时要也要控制主从库延迟（可以通过暂时剔除延迟高的节点，延迟低的时候再将节点加入集群），尽可能降低不一致发生的概率。