如何保证缓存和数据库一致性?
如何保证缓存和数据库一致性?
- 引入缓存提高性能
- 缓存利用率和一致性问题
- 并发引起的一致性问题
- 删除缓存可以保证一致性吗?
- 如何保证两步都执行?
- 主从延迟和延迟双删问题
- 可以做到强一致性吗?
- 总结
如何保证缓存和数据库一致性?
很多人对这个问题依然有很多疑惑:
- 到底是更新缓存还是删除缓存?
- 选择先更新数据库再删除缓存,还是先删除缓存再更新数据库?
- 为什么要引入消息队列保证一致性?
- 延迟双删会产生哪些问题?到底要不要用?如何用?
引入缓存提高性能
我们从最简单的场景开始说起。
如果项目业务处于起步阶段,流量非常少,读写请求直接操作数据库即可,此时你的架构模型是这样:
但是随着业务量的增长,你的项目请求量越来越大,如果每次都从DB中读取,那必然会产生性能问题。
通常这个阶段会引入【缓存】来提高读写性能,架构模型就会发生转变:
目前主流的缓存中间件,当属Redis,不仅性能高,还支持多种数据类型,能更好的满足我们的业务需求。
但是加入缓存之后,就会面临这样的一个问题:之前数据只存放在数据库中,从数据库读取,现在要放到缓存中读取,具体要存储什么呢?
最简单直接的方案就是【全量数据刷到缓存中】
- 数据库的数据,全量刷到缓存中(不设置失效时间)
- 写请求只更新数据库,不更新缓存
- 启动一个定时任务,定时将数据库中的数据,同步更新到缓存中
这个方案的有点不必多说,所有请求都全部【命中】缓存,不需要经过数据库,性能非常高。
但是缺点也很明显,主要体现以下两点。
缓存利用率低
,不是所有的缓存都是热点,不经常访问的数据长期存放在缓存中,会导致资源浪费数据不一致
,因为采取的是【定时刷新缓存】的机制,导致缓存数据与数据库数据不一致(取决于定时刷新的频率)
所以,这个方案适用于【体量小】的业务,对数据一致性要求不高的业务场景。
那么,针对体量很大的业务场景,怎么解决这两个问题呢?
缓存利用率和一致性问题
先来看第一个问题,如何提高缓存利用率的问题。
说到这,想要缓存利用率【最大化】,我们很容易能想到的方案是,缓存中只保留最近访问或经常访问的【热点数据】。
我们可以这样优化
- 写请求依旧只写数据库
- 读请求先读缓存,如果缓存不在,则从数据库读取,并重建缓存
- 同时,写入缓存中的数据,都设置失效时间(错开失效时间)
这样一来,缓存中不经常访问的key,随着时间的推移,都会时间【过期】淘汰掉,最终缓存中保留的,都是热点数据,从而缓存的利用率得以最大化。
再看数据一致性的问题。
想要保证缓存和数据库【实时】一致,那就不能再使用定时任务刷新缓存的方案。
所以,当数据发生更新时,我们不仅要操作更新数据库,还要一并操作缓存。具体的操作就是修改一条数据时,不仅要更新数据库,连带着缓存一起更新,或者删除相应的缓存,再次访问时是会查询数据库后进行重建缓存。
但数据库和缓存都更新,有存在先后的问题,那对应的方案就有2个:
1.先更新缓存,后更新数据库
2.先更新数据库,后更新缓存
哪一个方案更好呢?
这里先不考虑并发的问题,正常情况下,无论谁先谁后,都可以让两者保持一致,但现在我们需要重点考虑【异常】情况。
因为操作是分两步,那么就有可能在【第一个成功,第二个失败】的情况发生。
1、先更新缓存,后更新数据库
如果更新成功了,但数据库更新失败,那么此时缓存中是最新值,但是数据库中是【旧值】
虽然此时请求可以命中缓存,拿到正确的值,但是一旦缓失,就会从数据库中读取到【旧值】,重建缓存也是这个旧值。
这时用户就会发现自己之前的修改【又变回去了】,对业务造成影响。
2、先更新数据库,后更新缓存
如果更新数据库成功了,但是缓存更新失败了,那么此时数据库中是最新的值,缓存中是【旧值】。
之后的读请求都读到的是旧数据,只有当缓存【失效】后,才能从数据库中得到正确的值。
这时用户就会发现,自己刚刚修改了数据,但发现不生效,过一段时间后,数据才变更过来,对业务也会有影响。
可见,无论是谁先谁后,但凡后者发生异常,就会对业务造成影响。那么怎样解决这个问题呢?
我们继续分析,除了操作失败问题,还有什么场景会影响数据一致性?
这里我们还要重点关注:并发问题
并发引起的一致性问题
假如我们采用【先更新数据库,在更新缓存】的方案,并且两步都可以成功执行的前提下,如果存在并发,会是什么情况呢?
有线程A 和线程 B 两个线程,需要更新【同一条数据】,会发生这样的场景:
- 线程A 更新数据库(X=1)
- 线程B 更新数据库(X=2)
- 线程B 更新缓存(X=2)
- 线程A 更新缓存(X=1)
最终 X 的值在缓存中是1 ,数据库中是2,发生不一致。
也就是说,A虽然先于B发生,但B操作数据库和缓存的时间,却要比B的时间更短,执行时序发生【错乱】,最终导致这条数据结果不符合预期的。
同样的,采用【新更新缓存,在更新数据库】的方案,也会有类似的问题。
除此之外,我们从【缓存利用率】的角度来评估这个方案,也是不太难推敲的。
这是因为每次数据发生变更,都更新缓存,但是缓存中的数据不一定会被马上读取,这就会导致缓存中存放了很多不常访问的数据,浪费缓存资源。
而且很多情况下,写到缓存中的值,并不是与数据库中的值一一对应的,很可能先查数据库,经过一系列计算得出的值,才把这个值写到缓存中。
由此可见,这种【更新数据库+更新缓存】的方案,不仅缓存利用率不到,还会造成服务器资源和性能的浪费。
所以此时我们需要考虑另外一种方案:删除缓存
删除缓存可以保证一致性吗?
删除缓存对应的方案也有 2 种:
- 先删除缓存,再更新数据库
- 先更新数据库,再删除缓存
经过前面的分析我们可以知道,但凡【第二步】操作失败,都会导致数据不一致。
1、先删除缓存,后更新数据库
如果有 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发生的概率是非常低的。
因为写数据库一般会先【加锁】,所以写数据库,通常是要比读数据库的时间更长的。
这么看来,【先更新数据库 + 再删除缓存】的方案,是可以保证数据一致性的。
所以,我们应该采用这种方案(【先更新数据库 + 再删除缓存】)来操作数据库和缓存。
嗯,解决了并发问题,我们继续来看前面遗留的,第二步执行失败,导致数据不一致的问题
如何保证两步都执行?
通过前面的分析,无论是更新缓存还是删除缓存,只要第二步出现失败,就会导致数据库和缓存的结果不一致。
保证第二步成功执行,就是解决问题的关键
程序在执行过程中发生异常,最简单的解决办法是:重试
但这并不意味着,只要执行失败(出现异常),我们重试就可以了。
实际情况往往没那么简单,失败后立即重试的问题在于:
- 立即重试很大概率还会失败
- 重试次数设置多少才合理
- 重试会一直占用这个线程资源,无法服务其他客户端请求
由此可见了,虽然我们想通过重试的方式解决问题,但是这种【同步重试】的方案依旧不严谨。
那么另一种更好的方案是:异步重试
异步重试,其实就是把重试请求放到【消息队列】中,然后由专门的消费者来进行重试,直到成功。
或者更直接的做法,为了避免第二次执行失败,我们可以把操作缓存这一步,直接放到消息队列中,由消费者来操作缓存。
这里你可能会疑惑,写队列也有可能会失败,而且引入消息队列,这又会增加了更多的维护成本,增加项目复杂度,这样做是否值得?
这是个好问题,抛开项目复杂度,我们思考这样一个问题:如果在执行失败的线程中一直重试,还没等执行成功,此时如果项目重启了,那么重试的请求就丢失了,这一条数据就不一致了。
所以,我们必须将重试或者第二步骤放到另一个服务中,这个服务用【消息队列】最为合适,因为消息队列的特性,可以满足我们的需求:
- 消息队列可靠性:写到队列中的消息,成功消费之前不会丢失(重启也不担心)
- 消息队列保证消息成功投递:消费者从队列拉取消息,成功消费后才会删除(message_id),否则还会继续投递消息给消费者(符合重试场景)
至于写队列失败和消息队列成本维护问题:
- 写入队列失败:操作缓存和写消息队列,同时失败的概率是非常小的
- 维护成本:达到一定量级,我们项目中都会使用消息队列,维护成本并没有增加很多
所以,引入消息队列来解决第二个步骤失败重试的问题,是比较合适的,这时候的架构就变成了这样:
如果不想在应用中去写消息队列,是否有更简单的方案,同时又可以保证一致性呢?
方案还是有的,这就是近几年比较流行的解决方案:订阅数据库变更日志,再操作缓存
具体来说就是,业务在修改数据时,只需修改数据库,无需操作缓存。
那什么时候操作缓存呢,这个就与数据库的【变更日志】有关
当一条数据发生改变时,MySQL就会产生一条binlog(变更日志)我们可以订阅这个日志,拿到具体操作的数据,然后再根据这条数据,去删除对应的缓存。
订阅变更日志,目前也有比较成熟的开源中间件,例如阿里的canal,使用这种方案的有点在于:
- 无需考虑写消息队列失败情况:只要写MySQL成功,Binlog肯定会有
- 自动投递到下游队列:canal自动把数据库变更日志【投递】给下游消息队列
当然,于此同时,我们需要投入经历去维护canal的高可用和稳定性。
根据数据库的特性,很多数据库都逐渐开始提供【订阅变更日志】的功能,到时候就不用通过中间件来拉取日志,可以自己写程序订阅变更日志,进一步简化流程。
到这里,可以得出的结论,想要保证数据和缓存一致性,推荐采用【先更新数据库,再删除缓存】的方案,并且配合【消息队列】或【订阅变更日志】的方式来做
主从延迟和延迟双删问题
到这里,还有两个问题
第一个问题:前面【先删缓存,再更新数据库】,导致不一致的问题。
第二个问题:关于【读写分离 + 主从复制延迟】情况下,缓存和数据库一致性的问题。
那么,如何解决这类的问题呢?
最有效的办法就是,将缓存删掉
但是不能立即删,而是需要【延迟删】,这就是:缓存延迟双删策略
按照这个延迟双删策略,这两个问题解决方案如下:
解决第一个问题:在线程A 删除缓存、更新完数据库之后,先【休眠一会】,再【删除】一次缓存。
解决第二个问题:可以生成一条【延迟消息】,写到消息队列中,消费者延迟删除缓存
这两个方案的目的都是为了将缓存清掉,这样一来,下次就可以从数据库读取到最新值,写入缓存。
但是相应的,这个延迟删除,延迟时间设置多久才合适?
- 问题1:延迟时间要大于主从复制的延迟时间
- 问题2:延迟时间要大于第二个线程读取数据+写入缓存的时间
但是,这个在实际分布式和高并发的场景中,很难评估时间的。
很多时候,我们都是凭借经验估算这个延迟时间,例如1~5s,这样也只是尽可能降低不一致的概率。
所以,极端的情况下,还是会有可能发生不一致。
可以做到强一致性吗?
如果想让缓存和数据到达到【强一致性】,其实很难做到的。
这往往要 牺牲性能
一旦我们使用缓存,就必然会出现一致性的问题,性能与一致性,无法做到保持平衡。势必会向一方倾斜。
如果非要达到强一致性,那就必须在完成更新操作之前,不能有任何请求处理,这在实际高并发的场景中是不可取的。
虽然也可以使用【分布式锁】来实现,但是加锁与释放的过程,也会降低其性能,有时候甚至会超过引入缓存带来的性能提升。
所以,我们既然决定使用缓存,就必须容忍【一致性】问题,我们只能尽可能地降低出现问题的概率
总结
- 将要提高应用性能,可以引入缓存来解决
- 引入缓存后,就要考虑缓存和数据库一致性的问题,建议,更新数据库,删除缓存
- 更新数据库 + 删除缓存的方案,在并发场景下无法保证缓存与数据保持一致性,且存在缓存资源浪费和机器性能浪费的情况。
- 并发场景下的延迟双删策略,这个延迟时间很难评估,所以推荐【先更新数据库,再删除缓存】的方案
- 在【先更新数据库,再删除缓存】的方案下,为了保证两步都能执行成功,需要配合【消息队列】或【订阅变更日志】的方案来做,其本质是通过重试的方式保证数据一致性。
- 在【先更新数据库,再删除缓存】方案下,【读写分离 + 主从延迟】也会导致缓存和数据库不一致,解次问题的方案是【延迟双删】,凭借经验发送【延迟消息】到队列中,延迟删除缓存,同时要也要控制主从库延迟(可以通过暂时剔除延迟高的节点,延迟低的时候再将节点加入集群),尽可能降低不一致发生的概率。
如何保证缓存和数据库一致性?相关推荐
- 怎么保证缓存和数据库一致性
背景 缓存是软件开发中一个非常有用的概念,数据库缓存更是在项目中必然会遇到的场景.而缓存一致性的保证,更是在面试中被反复问到,这里进行一下总结,针对不同的要求,选择恰到好处的一致性方案. 缓存是什么 ...
- 好文推荐 | 缓存与数据库一致性问题深度剖析 (修订)
点击上方"朱小厮的博客",选择"设为星标" 后台回复"书",获取 来源:后端技术漫谈 当我们在做数据库与缓存数据同步时,究竟更新缓存,还是删 ...
- 缓存和数据库一致性问题,看这篇就够了
作者 | Magic Kaito 来源 | 水滴与银弹 如何保证缓存和数据库一致性,这是一个老生常谈的话题了. 但很多人对这个问题,依旧有很多疑惑: 到底是更新缓存还是删缓存? 到底选择先更新数据库, ...
- Redis面试 - 如何保证缓存与数据库的双写一致性?
Redis面试 - 如何保证缓存与数据库的双写一致性? 面试题 如何保证缓存与数据库的双写一致性? 面试官心理分析 你只要用缓存,就可能会涉及到缓存与数据库双存储双写,你只要是双写,就一定会有数据一致 ...
- 缓存与数据库一致性保证
缓存与数据库一致性保证 本文主要讨论这么几个问题: (1)啥时候数据库和缓存中的数据会不一致 (2)不一致优化思路 (3)如何保证数据库与缓存的一致性 一.需求缘起 上一篇<缓存架构设计细节二三 ...
- Redis 缓存实战——缓存、数据库一致性问题分析与解决方案
引言 缓存与数据库一致性的问题自从出现了缓存概念后就一直被提及,它是一个缓存方案的先天缺陷,只要存在缓存,就势必会讨论缓存与数据库一致性的问题. 一致性问题还广泛存在于各种分布式存储场景中,如主从一致 ...
- 缓存和数据库一致性问题
文章目录 1. 缓存和数据库一致性问题 2. 三个经典的缓存模式 2.1 Cache-Aside 2.1.1 读缓存 2.1.2 写缓存 2.1.3 延迟双删 2.1.4 如何确保操作缓存和操作数据库 ...
- session.merge 缓存不更新_如何保证缓存与数据库双写时的数据一致性?
在做系统优化时,想到了将数据进行分级存储的思路.因为在系统中会存在一些数据,有些数据的实时性要求不高,比如一些配置信息.基本上配置了很久才会变一次.而有一些数据实时性要求非常高,比如订单和流水的数据. ...
- 高并发下如何保证缓存和数据库的数据一致性?
51CTO 缓存由于其高性能,支持高并发的特性,在高并发的项目中不可或缺.被大家广泛使用的有Redis,Memcached等.本文主要探讨几种常见的缓存的读写模式,以及如何来保证缓存和数据库的数据一致 ...
最新文章
- 简单介绍使用Nginx限制百度蜘蛛频繁抓取的问题
- 华为主题包hwt下载_华为手机非官方主题应用指南
- 服务端升级为select模型处理多客户端
- 巧识滤波、稳压、比较、运放电路
- Android之layout属性介绍
- python-数据类型-字符串入门-定符串的定义-type函数-iput函数
- 计算机图标用鼠标双击和右键都无法启动,电脑桌面只有“我的电脑”图标双击找不开,用右键资源管理器能打开,为什么...
- 业余学习python有用吗_对于那些不做编程工作的小伙伴来说,学习Python有什么用呢?...
- Java基础 -- 冒泡排序算法(带详细注释)
- Navicat Preminm注册机 和源文件
- android炫酷动画源码,QQ菜单、瀑布流、二维码源码
- python 视频剪辑软件_一个Python写的视频剪辑软件,好用!
- 浅谈软件工程学习心得
- Android指纹验证
- 乐山持点科技:抖音极速版电商入驻指南
- 16 tia 内容说明 安装包_TIA Portal V16 软件安装包 安装教程 授权
- element 实现头像上传
- 现代密码学概论(3 Edition)第一章
- 用python实现基于turtle生成彩虹糖(可根据自己的喜好调整彩虹棒棒糖的颜色)
- 手机访问网站,点击手机号码直接拨打电话