Mysql和Redis数据如何保持一致
先阐明一下Mysql和Redis的关系:Mysql是数据库,用来持久化数据,一定程度上保证数据的可靠性;Redis是用来当缓存,用来提升数据访问的性能。
关于如何保证Mysql和Redis中的数据一致(即缓存一致性问题),这是一个非常经典的问题。
使用过缓存的人都应该知道,在实际应用场景中,要想实时刻保证缓存和数据库中的数据一样,很难做到。
基本上都是尽可能让他们的数据在绝大部分时间内保持一致,并保证最终是一致的。
缓存不一致是如何产生的
如果数据一直没有变更,那么就不会出现缓存不一致的问题。
通常缓存不一致是发生在数据有变更的时候。 因为每次数据变更你需要同时操作数据库和缓存,而他们又属于不同的系统,无法做到同时操作成功或失败,总会有一个时间差。在并发读写的时候可能就会出现缓存不一致的问题(理论上通过分布式事务可以保证这一点,不过实际上基本上很少有人这么做)。
虽然没办法在数据有变更时,保证缓存和数据库强一致,但对缓存的更新还是有一定设计方法的,遵循这些设计方法,能够让这个不一致的影响时间和影响范围最小化。
缓存更新的几种设计
缓存更新的设计方法大概有以下四种:
先删除缓存,再更新数据库(这种方法在并发下最容易出现长时间的脏数据,不可取)
先更新数据库,删除缓存(Cache Aside Pattern)
只更新缓存,由缓存自己同步更新数据库(Read/Write Through Pattern)
只更新缓存,由缓存自己异步更新数据库(Write Behind Cache Pattern)
接下来详细介绍一些这四种设计方法
先删除缓存,再更新数据库
这种方法在并发读写的情况下容易出现缓存不一致的问题
如上图所示,其可能的执行流程顺序为:
客户端1 触发更新数据A的逻辑
客户端2 触发查询数据A的逻辑
客户端1 删除缓存中数据A
客户端2 查询缓存中数据A,未命中
客户端2 从数据库查询数据A,并更新到缓存中
客户端1 更新数据库中数据A
可见,最后缓存中的数据A跟数据库中的数据A是不一致的,缓存中的数据A是旧的脏数据。
因此一般不建议使用这种方式。
先更新数据库,再让缓存失效
这种方法在并发读写的情况下,也可能会出现短暂缓存不一致的问题
如上图所示,其可能执行的流程顺序为:
客户端1 触发更新数据A的逻辑
客户端2 触发查询数据A的逻辑
客户端3 触发查询数据A的逻辑
客户端1 更新数据库中数据A
客户端2 查询缓存中数据A,命中返回(旧数据)
客户端1 让缓存中数据A失效
客户端3 查询缓存中数据A,未命中
客户端3 查询数据库中数据A,并更新到缓存中
可见,最后缓存中的数据A和数据库中的数据A是一致的,理论上可能会出现一小段时间数据不一致,不过这种概率也比较低,大部分的业务也不会有太大的问题。
只更新缓存,由缓存自己同步更新数据库(Read/Write Through Pattern)
这种方法相当于是业务只更新缓存,再由缓存去同步更新数据库。 一个Write Through的 例子如下:
如上图所示,其可能执行的流程顺序为:
客户端1 触发更新数据A的逻辑
客户端2 触发查询数据A的逻辑
客户端1 更新缓存中数据A,缓存同步更新数据库中数据A,再返回结果
客户端2 查询缓存中数据A,命中返回
Read Through 和 WriteThrough 的流程类似,只是在客户端查询数据A时,如果缓存中数据A失效了(过期或被驱逐淘汰),则缓存会同步去数据库中查询数据A,并缓存起来,再返回给客户端
这种方式缓存不一致的概率极低,只不过需要对缓存进行专门的改造。
只更新缓存,由缓存自己异步更新数据库(Write Behind Cache Pattern)
这种方式性详单于是业务只操作更新缓存,再由缓存异步去更新数据库,例如:
如上图所示,其可能的执行流程顺序为:
客户端1 触发更新数据A的逻辑
客户端2 触发查询数据A的逻辑
客户端1 更新缓存中的数据A,返回
客户端2 查询缓存中的数据A,命中返回
缓存异步更新数据A到数据库中
这种方式的优势是读写的性能都非常好,基本上只要操作完内存后就返回给客户端了,但是其是非强一致性,存在丢失数据的情况。
如果在缓存异步将数据更新到数据库中时,缓存服务挂了,此时未更新到数据库中的数据就丢失了。
总结
上面讲到的几种缓存更新的设计方式,都是前人总结出来的经验,这些方式或多或少都有一些弊端,并不完美,实际上也很难有完美的设计。 大家在做系统设计的时候,也不要去追求完美,要有一些取舍,找到一种最适合自己业务场景的方式就行
作者:追光者

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Bundle-less 的思考和实践分享
作者:杨兴元 随着 Snowpack、Vite 等利用提倡 no-bundle 的构建工具逐渐兴起,同时现代浏览器对原生 ESM 的普遍支持,Bundle-less 的概念席卷前端圈,那么我们如何理解 Bundle-less?究竟是炒概念还是能够真正地给业界带来收益?下面就来分享一下我对于 Bundle-less 的理解以及在这个方向上做过的一些探索。 如何理解 Bundle-less? Bundle-less,也被叫做 Bundless,我觉得可以从这几个角度去理解: 首先是拆包,弱化传统意义上的打包概念,由单 bundle 拆分为数十或者上百个 bundle,这样可以更好地利用 HTTP2 的多路复用优势和提升缓存命中率。 然后是对于项目源代码不进行 bundle(no-bundle),在开发阶段可以省略 bundle 的开销,如 Vite、Snowpack、WMR,这层含义相信大家都比较熟悉了。 再者是依赖产物的模块化分发。对于庞大的外部依赖,一方面打包成本比较高,另一方面文件数量可能非常多,打包几乎是一个必选项,甚至需要多个 NPM 包合并打包。因此,针对依赖的打包也是非常重要...
- 下一篇
FlyFish|前端数据可视化开发避坑指南(二)
FlyFish是云智慧开源的一款数据可视化编排平台。通过配置数据模型为用户提供上百种可视化图形组件,零编码即可实现符合自己业务需求的炫酷可视化大屏。 同时,FlyFish也提供了灵活的拓展能力,支持组件开发、自定义函数与全局事件等配置, 面向复杂需求场景能够保证高效开发与交付。 需注意,本避坑指南仅针对云智慧开源数据可视化平台FlyFish。如果你也对数据可视化感兴趣,欢迎点击 FlyFish,给 FlyFish Star。以及微信添加xiaoyuerwise回复飞鱼,加入 FlyFish开发者交流群一起探讨。 前篇:FlyFish|前端数据可视化开发避坑指南(一) Q1:从 FlyFish Demo环境中导出的模板,运行显示黑屏? A1:8848端口后边还跟了路由分发的东西,因此是拿不到组件的js文件的。需要修改config/env.js里边的componentDir加上配置的'/screen_62c93bd260e71f0e9d29bd5f'。 Q2:生成的大屏页面需要滚动才能查看,且尺寸大于 1920 时会出现左右留白情况? A2:可通过缩放的方式解决上述问题,具体如下图所示 Q...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2全家桶,快速入门学习开发网站教程
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- 2048小游戏-低调大师作品
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- CentOS7,8上快速安装Gitea,搭建Git服务器
- CentOS6,CentOS7官方镜像安装Oracle11G
- CentOS关闭SELinux安全模块