论坛
潜水/灌水快乐,沉淀知识,认识更多同行。
ToB圈子
加入IT圈,遇到更多同好之人。
朋友圈
看朋友圈动态,了解ToB世界。
ToB门户
了解全球最新的ToB事件
博客
Blog
排行榜
Ranklist
文库
业界最专业的IT文库,上传资料也可以赚钱
下载
分享
Share
导读
Guide
相册
Album
记录
Doing
搜索
本版
文章
帖子
ToB圈子
用户
免费入驻
产品入驻
解决方案入驻
公司入驻
案例入驻
登录
·
注册
只需一步,快速开始
账号登录
立即注册
找回密码
用户名
Email
自动登录
找回密码
密码
登录
立即注册
首页
找靠谱产品
找解决方案
找靠谱公司
找案例
找对的人
专家智库
悬赏任务
圈子
SAAS
ToB企服应用市场:ToB评测及商务社交产业平台
»
论坛
›
数据库
›
SqlServer
›
让MySQL和Redis数据保持一致的4种策略
让MySQL和Redis数据保持一致的4种策略
勿忘初心做自己
金牌会员
|
2024-6-14 23:27:44
|
显示全部楼层
|
阅读模式
楼主
主题
578
|
帖子
578
|
积分
1734
1 前言
先分析一下 MySQL 和 Redis 的关系:MySQL 是数据库,用来长期化数据,一定程度上包管数据的可靠性;Redis 是用来当缓存,用来提升数据访问的性能。
关于如何包管 MySQL 和 Redis 中的数据一致(即缓存一致性题目),这是一个非常经典的题目。
使用过缓存的人都应该知道,在现实应用场景中,要想及时候包管缓存和数据库中的数据一样,很难做到。
基本上都是尽大概让他们的数据在绝大部分时间内保持一致,并包管最终是一致的。
1.1 缓存不一致是如何产生的
如果数据不绝没有变更,那么就不会出现缓存不一致的题目。
通常缓存不一致是发生在数据有变更的时间。因为每次数据变更你需要同时操纵数据库和缓存,而他们又属于不同的体系,无法做到同时操纵成功或失败,总会有一个时间差。在并发读写的时间大概就会出现缓存不一致的题目(理论上通太过布式事务可以包管这一点,不过现实上基本上很少有人这么做)。
虽然没办法在数据有变更时,包管缓存和数据库强一致,但对缓存的更新还是有一定设计方法的,遵循这些设计方法,能够让这个不一致的影响时间和影响范围最小化。
1.2 缓存更新的几种设计
缓存更新的设计方法大概有以下四种:
先删除缓存,再更新数据库(这种方法在并发下最容易出现长时间的脏数据,不可取)
先更新数据库,删除缓存(Cache Aside Pattern)
只更新缓存,由缓存自己同步更新数据库(Read/Write Through Pattern)
只更新缓存,由缓存自己异步更新数据库(Write Behind Cache Pattern)
接下来具体介绍一些这四种设计方法
2 设计方法一:先删除缓存,再更新数据库
这种方法在并发读写的情况下容易出现缓存不一致的题目
如上图所示,其大概的实行流程顺序为:
客户端1 触发更新数据A的逻辑
客户端2 触发查询数据A的逻辑
客户端1 删除缓存中数据A
客户端2 查询缓存中数据A,未掷中
客户端2 从数据库查询数据A,并更新到缓存中
客户端1 更新数据库中数据A
可见,末了缓存中的数据 A 跟数据库中的数据 A 是不一致的,缓存中的数据A是旧的脏数据。
因此一般不建议使用这种方式。
3 设计方法二:先更新数据库,再让缓存失效
这种方法在并发读写的情况下,也大概会出现短暂缓存不一致的题目
如上图所示,其大概实行的流程顺序为:
客户端1 触发更新数据A的逻辑
客户端2 触发查询数据A的逻辑
客户端3 触发查询数据A的逻辑
客户端1 更新数据库中数据A
客户端2 查询缓存中数据A,掷中返回(旧数据)
客户端1 让缓存中数据A失效
客户端3 查询缓存中数据A,未掷中
客户端3 查询数据库中数据A,并更新到缓存中
可见,末了缓存中的数据A和数据库中的数据 A 是一致的,理论上大概会出现一小段时间数据不一致,不过这种概率也比力低,大部分的业务也不会有太大的题目。
4 设计方法三:只更新缓存,由缓存自己同步更新数据库(Read/Write Through Pattern)
只更新缓存,由缓存自己同步更新数据库(Read/Write Through Pattern)
如上图所示,其大概实行的流程顺序为:
客户端1 触发更新数据 A 的逻辑
客户端2 触发查询数据 A 的逻辑
客户端1 更新缓存中数据 A,缓存同步更新数据库中数据 A,再返回效果
客户端2 查询缓存中数据 A,掷中返回
Read Through 和 WriteThrough 的流程雷同,只是在客户端查询数据A时,如果缓存中数据A失效了(逾期或被驱逐淘汰),则缓存会同步去数据库中查询数据A,并缓存起来,再返回给客户端。
这种方式缓存不一致的概率极低,只不过需要对缓存举行专门的改造。
5 只更新缓存,由缓存自己异步更新数据库(Write Behind Cache Pattern)
这种方式性详单于是业务只操纵更新缓存,再由缓存异步去更新数据库,例如:
如上图所示,其大概的实行流程顺序为:
客户端1 触发更新数据 A 的逻辑
客户端2 触发查询数据 A 的逻辑
客户端1 更新缓存中的数据 A,返回
客户端2 查询缓存中的数据 A,掷中返回
缓存异步更新数据 A 到数据库中
这种方式的上风是读写的性能都非常好,基本上只要操纵完内存后就返回给客户端了,但是其是非强一致性,存在丢失数据的情况。
如果在缓存异步将数据更新到数据库中时,缓存服务挂了,此时未更新到数据库中的数据就丢失了。
6 小结
上面讲到的几种缓存更新的设计方式,都是前人总结出来的经验,这些方式或多或少都有一些弊端,并不完善,现实上也很难有完善的设计。大家在做体系设计的时间,也不要去追求完善,要有一些弃取,找到一种最适合自己业务场景的方式就行。
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。
本帖子中包含更多资源
您需要
登录
才可以下载或查看,没有账号?
立即注册
x
回复
使用道具
举报
0 个回复
正序浏览
返回列表
快速回复
高级模式
B
Color
Image
Link
Quote
Code
Smilies
您需要登录后才可以回帖
登录
or
立即注册
本版积分规则
发表回复
回帖并转播
发新帖
回复
勿忘初心做自己
金牌会员
这个人很懒什么都没写!
楼主热帖
集合论第6-8章
Java 代理模式
将git仓库从submodule转换为subtree ...
反射 p1 反射机制
如何爆破js加密后的密码?
数字工厂介绍
新一代企业级安全OneDNS
【技术积累】Mysql中的SQL语言【技术篇 ...
java -- Stringbuild、Date和Calendar ...
SignalR 2 与mvc 5实现实时聊天功能 ...
标签云
挺好的
服务器
快速回复
返回顶部
返回列表