缓存和数据库一致性解决方案看这一篇就够了
引入缓存提高性能
如果你的业务处于起步阶段,流量非常小,那无论是读请求还是写请求,直接操作数据库即可,这时你的架构模型是这样的:
但随着业务量的增长,你的项目请求量越来越大,这时如果每次都从数据库中读数据,那肯定会有性能问题。
这个阶段通常的做法是,引入「缓存」来提高读性能,架构模型就变成了这样:
如何提高缓存利用率?
想要缓存利用率「最大化」,我们很容易想到的方案是,缓存中只保留最近访问的「热数据」。
-
写请求依旧只写数据库
-
读请求先读缓存,如果缓存不存在,则从数据库读取,并重建缓存
-
同时,写入缓存中的数据,都设置失效时间
缓存中不经常访问的数据,随着时间的推移,都会逐渐「过期」淘汰掉,最终缓存中保留的,都是经常被访问的「热数据」,缓存利用率得以最大化。
如何保证缓存和数据库数据的一致性?
更新缓存和数据库有四种方案:
-
先更新缓存,再更新数据库
-
先更新数据库,再更新缓存
-
先删除缓存,后更新数据库
-
先更新数据库,后删除缓存
更新缓存
优点:如果每次数据变化都能被及时更新,那么查询数据时不容易出现不命中的情况, 缺点:1、如果数据的计算复杂,频繁的更新会造成服务器性能的消耗比较大 2、如果数据并不是被频繁使用,那么频繁更新也只是浪费服务器性能,对业务没有多大的帮助
删除缓存
优点:不需要顾忌数据的复杂性,直接删除即可 缺点:查询数据时,增大未命中的几率,从而增大数据库的访问压力 适用于数据使用频率不高的场景
先更新缓存,再更新 DB
这个方案一般不考虑。原因是更新缓存成功,更新数据库出现异常了, 导致缓存数据与数据库数据完全不一致,而且很难察觉,因为缓存中的数据一直都存在。
先更新 DB,再更新缓存
如果数据库更新成功了,但缓存更新失败,那么此时数据库中是最新值,缓存中是「旧值」。之后的读请求读到的都是旧数据,只有当缓存「失效」后,才能从数据库中得到正确的值。这种方案一般不考虑。
并发引发的一致性问题
同时有请求 A 和请求 B 进行更新操作,那么会出现
(1)线程 A 更新了数据库
(2)线程 B 更新了数据库
(3)线程 B 更新了缓存
(4)线程 A 更新了缓存
线程1 虽然先于 线程2 发生,但 线程2 操作数据库和缓存的时间,却要比 线程1 的时间短,执行时序发生「错乱」,最终这条数据结果是不符合预期的。
如果是写多读少的场景,采用 这种方案就会导致,数据压根还没读到,缓存就被频繁的更新,浪费性能。
先删除缓存,后更新 DB
如果出现这样情况:1、线程A更新数据库中的数据 2、线程A删除缓存中的数据,删除失败 3、线程B查询缓存中的数据,查询到旧数据 4、线程A异步重试删除缓存 这里,删除缓存中数据失败后就会造成线程B获取到缓存中的旧数据,从而导致数据不一致的情况。
还有并发情况:
来了两个请求,请求 A(更新操作) 和请求 B(查询操作)
请求 A 会先删除 Redis 中的数据,然后去数据库进行更新操作;
此时请求 B 看到 Redis 中的数据时空的,会去数据库中查询该值,更新到Redis 中;
但是此时请求 A 并没有更新成功,或者事务还未提交,请求 B 去数据库查询得到旧值;
可见,先删除缓存,后更新数据库,当发生「读+写」并发时,还是存在数据不一致的情况。
如何解决呢?其 实最简单的解决办法就是延时双删的策略。
(1)先淘汰缓存
(2)再写数据库
(3)休眠 1 秒,再次淘汰缓存 这么做,可以将 1 秒内所造成的缓存脏数据,再次删除。
那么,这个 1 秒怎么确定的,具体该休眠多久呢?针对上面的情形,自行评估自己的项目的读数据业务逻辑的耗时。然后写数 据的休眠时间则在读数据业务逻辑的耗时基础上,加几百 ms 即可。这么做的目 的,就是确保读请求结束,写请求可以删除读请求造成的缓存脏数据。
如果Mysql 的读写分离的架构的话,那么其实主从同步之间也会有时间差。
请求 A(更新操作) 和请求 B(查询操作)
-
线程 A 更新主库 X = 2(原值 X = 1)
-
线程 A 删除缓存
-
线程 B 查询缓存,没有命中,查询「从库」得到旧值(从库 X = 1)
-
从库「同步」完成(主从库 X = 2)
-
线程 B 将「旧值」写入缓存(X = 1)
此时的解决办法有两个:
1、还是使用双删延时策略。只是,睡眠时间修改为在主从同步的延时时间基础上,加几百 ms。
2、就是如果是对 Redis 进行填充数据的查询数据库操作,那么就强制将其指向主库进行查询。
这个「延迟删除」缓存,延迟时间到底设置要多久呢?
-
问题1:延迟时间要大于「主从复制」的延迟时间
-
问题2:延迟时间要大于线程 B 读取数据库 + 写入缓存的时间
但是,这个时间在分布式和高并发场景下,其实是很难评估的。
很多时候,我们都是凭借经验大致估算这个延迟时间,例如延迟 1-5s,只能尽可能地降低不一致的概率。
所以你看,采用这种方案,也只是尽可能保证一致性而已,极端情况下,还是有可能发生不一致。
所以实际使用中,建议采用「先更新数据库,再删除缓存」的方案,同时,要尽可能地保证「主从复制」不要有太大延迟,降低出问题的概率。
先更新数据库,后删除缓存
先分析有失败情况:1、线程A更新数据库中的数据 2、线程A删除缓存中的数据,删除失败 3、线程B查询缓存中的数据,查询到旧数据 4、线程A异步重试删除缓存 这里,删除缓存中数据失败后就会造成线程B获取到缓存中的旧数据,从而导致数据不一致的情况
假设这会有两个请求,一个请求 A 做查询操作,一个请求 B 做 更新操作,那么会有如下情形产生
(1)缓存刚好失效
(2)请求 A 查询数据库,得一个旧值
(3)请求 B 将新值写入数据库
(4)请求 B 删除缓存
(5)请求 A 将查到的旧值写入缓存
其实概率「很低」,这是因为它必须满足 3 个条件:
-
缓存刚好已失效
-
读请求 + 写请求并发
-
更新数据库 + 删除缓存的时间(步骤 3-4),要比读数据库 + 写缓存(步骤 2 和 5)时间短
仔细想一下,条件 3 发生的概率其实是非常低的。
因为写数据库一般会先「加锁」,所以写数据库,通常是要比读数据库的时间更长的。这么来看,「先更新数据库 + 再删除缓存」的方案,是可以保证数据一致性的。
更新数据库成功了,但是在删除缓存的阶段出错了没有删除成功怎么办? 这个问题,在删除缓存类的方案都是存在的,那么此时再读取缓存的时候每次都是错误的数据了。
此时解决方案有两个,一是就是利用消息队列进行删除的补偿:
1、请求 A 先对数据库进行更新操作
2、在对 Redis 进行删除操作的时候发现报错,删除失败
3、此时将 Redis 的 key 作为消息体发送到消息队列中
4、系统接收到消息队列发送的消息后
5、再次对 Redis 进行删除操作
第二种方案,订阅数据库变更日志,再操作缓存。
具体来讲就是,我们的业务应用在修改数据时,「只需」修改数据库,无需操作缓存。
那什么时候操作缓存呢?这就和数据库的「变更日志」有关了。
拿 MySQL 举例,当一条数据发生修改时,MySQL 就会产生一条变更日志(Binlog),我们可以订阅这个日志,拿到具体操作的数据,然后再根据这条数据,去删除对应的缓存。
想要保证数据库和缓存一致性,推荐采用「先更新数据库,再删除缓存」方案,并配合「消息队列」或「订阅变更日志」的方式来做。
总结
引入缓存后,需要考虑缓存和数据库一致性问题,可选的方案有:「更新数据库 + 更新缓存」、「更新数据库 + 删除缓存」
更新数据库 + 更新缓存方案,在「并发」场景下无法保证缓存和数据一致性,且存在「缓存资源浪费」和「机器性能浪费」的情况发生
在更新数据库 + 删除缓存的方案中,「先删除缓存,再更新数据库」在「并发」场景下依旧有数据不一致问题,解决方案是「延迟双删」,但这个延迟时间很难评估,所以推荐用「先更新数据库,再删除缓存」的方案
在「先更新数据库,再删除缓存」方案下,为了保证两步都成功执行,需配合「消息队列」或「订阅变更日志」的方案来做,本质是通过「重试」的方式保证数据一致性
在「先更新数据库,再删除缓存」方案下,「读写分离 + 主从库延迟」也会导致缓存和数据库不一致,缓解此问题的方案是「延迟双删」,凭借经验发送「延迟消息」到队列中,延迟删除缓存,同时也要控制主从库延迟,尽可能降低不一致发生的概率。
掌握缓存和数据库一致性问题,核心问题有 3 点:缓存利用率、并发、缓存 + 数据库一起成功问题。
对于并发几率很小的数据(如个人维度的订单数据、用户数据等),这种几乎不用考虑这个问题,很少会发生缓存不一致,可以给缓存数据加上过期时间,每隔一段时间触发读的主动更新即可。
就算并发很高,如果业务上能容忍短时间的缓存数据不一致(如商品名称,商品分类菜单等),缓存加上过期时间依然可以解决大部分业务对于缓存的要求。
如果不能容忍缓存数据不一致,可以通过加分布式读写锁保证并发读写或写写的时候按顺序排好队,读读的 时候相当于无锁。
发表评论