为什么要引入缓存？数据一致性与缓存利用率的优化方向

最新推荐文章于 2024-07-20 14:37:54 发布

im-xia

最新推荐文章于 2024-07-20 14:37:54 发布

阅读量400

点赞数 6

文章标签：缓存 java 开发语言

本文链接：https://blog.csdn.net/x_023/article/details/136436173

版权

为什么要引入缓存？

确定引入缓存时应该考虑的两个指标

方案 1 ：全量数据刷入缓存

最简单直接的方案，写操作只操作数据库、启动定时任务定时将数据库中全量数据刷入缓存中去，不设置失效时间
缓存命中率为百分之百，性能很高，但缓存利用率低，数据一致性取决于定时任务的执行频率
业务体量小时还可以，因为缓存不会占用太多空间，且刷缓存效率不会很低。但这就会产生一个悖论，业务体量小的时候一般也不需要引入缓存，因为缓存解决的首要问题就是业务量大时的数据查询效率问题

缓存利用率优化

缓存一致性优化

方案 2 ：先更新缓存，再更新数据库 / 先更新数据库，再更新缓存

将两种方案一起介绍主要是因为这两种方案都存在写写并发环境中的数据一致性问题，并且每次都更新缓存在经常写的场景中无效写操作较多
比如线程 A 更新数据库 X = 1 ；线程 B 更新数据库 X = 2 ；线程 B 更新缓存 X = 2 ；线程 A 更新缓存 X = 1 。最终数据库 X = 2 ，缓存 X = 1 ，在缓存失效之前所有查询操作查询到的 X 都是错误的
上面是先更新数据库再更新缓存情况下的数据一致性问题，反过来也是一样的

方案 3 ：先删除缓存，再更新数据库

写写并发时永远不会有一致性问题，因为缓存被删除了
读写并发时的数据一致性问题：线程 A 先删除缓存 X ，线程 B 读取 X 发现缓存中没有，读取数据库 X = 1 ，线程 B 建立缓存 X = 1 ，线程 A 更新数据库 X = 2

方案 4 ：先更新数据库，再删除缓存

和方案 3 一样，不存在写写并发时的不一致问题
读写并发时的数据一致性问题：线程 A 读取 X 发现缓存中没有，去读取数据库 X = 1 ，线程 B 更新数据库 X = 2 ，线程 B 删除缓存，线程 A 建立缓存 X = 1

方案 3 与 4 的对比

对比方案 3 ，方案 4 出现数据不一致的概率极小，第一条就是正好还没有建立缓存或者缓存正好过期，此时有线程读取数据库，并且到其建立缓存这段时间内，其他线程需要完成并发写该数据并删除缓存

方案 5 ：延迟双删策略

观察删除缓存的两种策略，发现最终造成缓存不一致的原因都是缓存被回种为旧值
在先删除缓存，再更新数据库时，可以在更新完数据库之后延迟一段时间，再删除一次缓存，确保这段时间内并发建立的错误缓存被删掉
在先更新数据库，再删除缓存的情况，我们可以不直接删除缓存，而是延迟一段时间后再删除缓存，确保这段时间内并发建立的错误缓存被删掉
比较两种方案，发现后者在更新数据库和延迟删除缓存的这段时间内，如果有其他请求并发查询，且有缓存存在的情况中，会导致查询到的数据为旧值，出现短暂的不一致情况（取决于延迟的长短），所以我们在延迟双删策略中偏向使用删除缓存，更新数据库，延迟删除缓存的策略
这种延迟删除的方案可以引入消息中间件异步进行，还可以进一步确保删除操作必定成功

总结：所有方案都无法做到强一致，就像 CAP 定理中所描述的一样，我们引入缓存的目的就是提高用户感知的可用性，所以也只能在这个基础上尽量提高一致性，追求强一致的结果只能是牺牲可用性，这就与我们引入缓存的初衷背道而驰了

关注