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

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

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

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

引入缓存提高性能

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

如果项目业务处于起步阶段,流量非常少,读写请求直接操作数据库即可,此时你的架构模型是这样:
在这里插入图片描述

但是随着业务量的增长,你的项目请求量越来越大,如果每次都从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,这样也只是尽可能降低不一致的概率。

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

可以做到强一致性吗?

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

这往往要 牺牲性能

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

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

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

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

总结

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

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 8
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值