并发环境下,先操作数据库还是先操作缓存?
(给ImportNew加星标,提高Java技能)
转自:捡田螺的小男孩
在分布式系统中,缓存和数据库同时存在时,如果有写操作,先操作数据库还是先操作缓存呢?本文将分5种方案展开阐述对比,谢谢阅读~
缓存维护方案一
如果是一读(线程B)一写(线程A)操作,「先操作缓存,再操作数据库」。流程图如下所示:
线程 A 发起一个写操作,第一步 del cache;
线程 A 第二步写入新数据到 DB;
线程 B 发起一个读操作,cache miss 缓存失效了;
线程 B 从 DB 获取最新数据;
线程 B 执行 set cache,把从 DB 读到的数据,更新到缓存。
这样看,没啥问题。我们再看第二个流程图:
线程 A 发起一个写操作,第一步 del cache;
此时线程 B 发起一个读操作,cache miss;
线程 B 继续读 DB,读出来一个老数据;
然后老数据设置入 cache;
线程 A 写入 DB 最新的数据。
OK,酱紫,就有问题了吧,老数据入到缓存了,每次读都是老数据啦,缓存与数据与数据库数据不一致了。
缓存维护方案二
上个方案是一读一写,如果是双写操作,先操作缓存,在操作数据库,会怎么样呢?
线程 A 发起一个写操作,第一步 set cache;
线程 A 第二步写入新数据到 DB;
线程 B 发起一个写操作,set cache;
线程 B 第二步写入新数据到 DB。
这样看,也没啥问题。但是有时候可能事与愿违,我们再看第二个流程图:
线程 A 发起一个写操作,第一步 set cache;
线程 B 发起一个写操作,第一步 set cache;
线程 B 写入数据库到 DB;
线程 A 写入数据库到 DB。
执行完后,缓存保存的是 B 操作后的数据,数据库是 A 操作后的数据,缓存和数据库数据不一致了。
缓存维护方案三
一写(线程 A)一读(线程 B)操作,先操作数据库,再操作缓存。
线程 A 发起一个写操作,第一步 write DB;
线程 A 第二步 del cache;
线程 B 发起一个读操作,cache miss;
线程 B 从 DB 获取最新数据;
线程 B 同时 set cache。
有些朋友可能认为,在第 2 步删除缓存之前,线程 B 读过来呢?这时候,读到的是缓存老数据,这个可以认为是正常业务逻辑呀,下次再读取就是正确数据了。
这种方案没有明显的并发问题。但步骤二删除缓存失败还是个问题,不过概率比较小,优于方案一和方案二,平时工作中也是使用方案三。
综上对比,我们一般采用方案三,但是有没有完美全解决方案三的弊端的方法呢?
缓存维护方案四
这个是方案三的改进方案,都是先操作数据库再操作缓存,我们来看一下流程图:
通过数据库的 binlog 来异步淘汰 key。以 MySQL 为例 ,可以使用阿里的 canal 将 binlog 日志采集发送到 MQ 队列里面,然后通过 ACK 机制 确认处理这条更新消息,删除缓存,保证数据缓存一致性。
但是呢还有个问题,如果是主从数据库呢?
缓存维护方案五
主从 DB 问题:因为主从 DB 同步存在延时时间。如果删除缓存之后,数据同步到备库之前已经有请求过来时,会从备库中读到脏数据,如何解决呢?解决方案如下流程图:
缓存维护总结
综上所述,在分布式系统中,缓存和数据库同时存在时,如果有写操作的时候,先操作数据库,再操作缓存。如下:
读取缓存中是否有相关数据; 如果缓存中有相关数据 value,则返回; 如果缓存中没有相关数据,则从数据库读取相关数据放入缓存中 key->value,再返回; 如果有更新写数据,则先操作数据库,再操作缓存; 为了保证第四步更新缓存成功,使用 binlog 异步通知操作; 如果是主从数据库,binglog 取自于从库; 如果是一主多从,每个从库都要采集 binlog,然后消费端收到最后一台 binlog 数据才删除缓存。
Redis 分布式缓存 Java 框架
【讨论】:缓存同步、如何保证缓存一致性、缓存误用
看完本文有收获?请转发分享给更多人
关注「ImportNew」,提升Java技能
好文章,我在看❤️