什么是数据库与缓存一致性 数据一致性指的是:缓存的数据值 = 数据库中的值 为什么会出现数据一致性问题呢? 在高并发的业务场景下,数据库大多数情况都是用户并发访问最薄弱的环节。所以,就需要使用Red
下面详细介绍
1. 先更新Mysql,再更新Redis
图解说明:
- 这是一副时序图,描述请求的先后调用顺序;
- 橘黄色的线是请求 A,黑色的线是请求 B;
- 橘黄色的文字,是 MySQL 和 Redis 最终不一致的数据;
- 数据是从 10 更新为 11,但是Redis中的数据还是10;
- 后面所有的图,都是这个含义,不再赘述。
请求 A、B 都是先写 MySQL,然后再写 Redis,在高并发情况下,如果请求 A 在写 Redis 时卡了一会,请求 B 已经依次完成数据的更新,就会出现图中的问题。
2. 先更新Redis,再更新Mysql
同“先写 MySQL,再写 Redis”,看图可秒懂。
3. 先删除Redis,再更新Mysql
请求 A 先删除缓存,可能因为卡顿,数据一直没有更新到 MySQL,导致两者数据不一致。这种情况出现的概率比较大,因为请求 A 更新 MySQL 可能耗时会比较长,而请求 B 的前两步都是查询,会非常快。
4. 先删除Redis,再更新Mysql,再删Redis
对于“先删除 Redis,再写 MySQL”,如果要解决最后的不一致问题,其实再对 Redis 重新删除即可,这个也是大家常说的“延迟双删”,不过最后一次删除Redis的时间需要评估业务逻辑执行的时间,即需要等请求B执行完毕再删除。
5. 先更新Mysql,再删Redis
对于上面这种情况,对于第一次查询,请求 B 查询的数据是 10,但是 MySQL 的数据是 11,只存在这一次不一致的情况,对于不是强一致性要求的业务,可以容忍。(那什么情况下不能容忍呢,比如秒杀业务、库存服务等。)
6. 先更新 MySQL,通过 Binlog,异步更新 Redis
这种方案,主要是监听 MySQL 的 Binlog,然后通过异步的方式,将数据更新到 Redis,这种方案有个前提,查询的请求,不会回写 Redis,这个方案,是实现最终一致性的终极解决方案,但是不能保证实时性。
先更新 Redis,再更新 MySQL
先更新 MySQL,再更新 Redis
先删除 Redis,再更新 MySQL
先删除 Redis,再更新 MySQL,再删除 Redis
先更新MySQL,再删除 Redis
先更新 MySQL,通过canal监听 Binlog,异步更新 Redis
来源地址:https://blog.csdn.net/qq_40782372/article/details/129115718
--结束END--
本文标题: Mysql和Redis数据一致性
本文链接: https://www.lsjlt.com/news/399101.html(转载时请注明来源链接)
有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341
下载Word文档到电脑,方便收藏和打印~
2024-05-21
2024-05-21
2024-05-21
2024-05-21
2024-05-21
2024-05-21
2024-05-21
2024-05-21
2024-05-21
2024-05-21
回答
回答
回答
回答
回答
回答
回答
回答
回答
回答
0