缓存一致性问题,这么回答肯定没毛病!

本文涉及的产品
云数据库 Redis 版,社区版 2GB
推荐场景:
搭建游戏排行榜
简介: 方案分析更新缓存策略方式常见的有下面几种:先更新缓存,再更新数据库先更新数据库,再更新缓存先删除缓存,再更新数据库先更新数据库,再删除缓存下面一一介绍!方案一:更新缓存,更新数据库这种方式可轻易排除,因为如果先更新缓存成功,但是数据库更新失败,则肯定会造成数据不一致。方案二:更新数据库,更新缓存这种缓存更新策略俗称双写,存在问题是:并发更新数据库场景下,会将脏数据刷到缓存updateDB();updateRedis();复制代码举例:如果在两个操作之间数据库和缓存又被后面请求修改,此时再去更新缓存已经是过期数据了。方案三:删除缓存,更新数据库存在问题:更新数据库之前,若有查询请求,会将举例

前言

一道之前的面试题:

如何保证缓存和数据库的一致性?

来自:社招一年半面经分享(含阿里美团头条京东滴滴)

  • 文章首发在公众号(月伴飞鱼),之后同步到个人网站:xiaoflyfish.cn/

微信搜索:月伴飞鱼,交个朋友,进面试交流群

  • 公众号后台回复666,可以获得免费电子书籍

觉得不错,希望点赞,在看,转发支持一下,谢谢

下面介绍几种方案(大家回答的时候最好根据自己的业务,结合下面的方案)


方案分析

更新缓存策略方式常见的有下面几种:

  1. 先更新缓存,再更新数据库
  2. 先更新数据库,再更新缓存
  3. 先删除缓存,再更新数据库
  4. 先更新数据库,再删除缓存

下面一一介绍!

方案一:更新缓存,更新数据库

这种方式可轻易排除,因为如果先更新缓存成功,但是数据库更新失败,则肯定会造成数据不一致。

方案二:更新数据库,更新缓存

这种缓存更新策略俗称双写,存在问题是:并发更新数据库场景下,会将脏数据刷到缓存

updateDB();
updateRedis();

举例:如果在两个操作之间数据库和缓存又被后面请求修改,此时再去更新缓存已经是过期数据了。

方案三:删除缓存,更新数据库

存在问题:更新数据库之前,若有查询请求,会将脏数据刷到缓存

deleteRedis();
updateDB();

举例:如果在两个操作之间发生了数据查询,那么会有旧数据放入缓存。

该方案会导致请求数据不一致

如果同时有一个请求A进行更新操作,另一个请求B进行查询操作。那么会出现如下情形:

  • 请求A进行写操作,删除缓存
  • 请求B查询发现缓存不存在
  • 请求B去数据库查询得到旧值
  • 请求B将旧值写入缓存
  • 请求A将新值写入数据库

上述情况就会导致不一致的情形出现。而且,如果不采用给缓存设置过期时间策略,该数据永远都是脏数据。

方案四:更新数据库,删除缓存

存在问题:在更新数据库之前有查询请求,并且缓存失效了,会查询数据库,然后更新缓存。如果在查询数据库和更新缓存之间进行了数据库更新的操作,那么就会把脏数据刷到缓存

updateDB();
deleteRedis();

举例:如果在查询数据库和放入缓存这两个操作中间发生了数据更新并且删除缓存,那么会有旧数据放入缓存。

假设有两个请求,一个请求A做查询操作,一个请求B做更新操作,那么会有如下情形产生

  • 缓存刚好失效
  • 请求A查询数据库,得一个旧值
  • 请求B将新值写入数据库
  • 请求B删除缓存
  • 请求A将查到的旧值写入缓存

如果发生上述情况,确实是会发生脏数据。但是发生上述情况有一个先天性条件,就是写数据库操作比读数据库操作耗时更短

不过数据库的读操作的速度远快于写操作的

因此这一情形很难出现。


方案对比

方案1和方案2的共同缺点:

并发更新数据库场景下,会将脏数据刷到缓存,但一般并发写的场景概率都相对小一些;

线程安全角度,会产生脏数据,比如:

  • 线程A更新了数据库
  • 线程B更新了数据库
  • 线程B更新了缓存
  • 线程A更新了缓存

方案3和方案4的共同缺点:

不管采用哪种顺序,2种方式都是存在一些问题的:

  • 主从延时问题:不管是先删除还是后删除,数据库主从延时可能导致脏数据的产生。
  • 缓存删除失败:如果缓存删除失败,则都会产生脏数据。

问题解决思路:延迟双删,添加重试机制,下面介绍!

更新缓存还是删除缓存?

1.更新缓存缓存需要有一定的维护成本,而且会存在并发更新的问题

2.写多读少的情况下,读请求还没有来,缓存以及被更新很多次,没有起到缓存的作用

3.放入缓存的值可能是经过复杂计算的,如果每次更新,都计算写入缓存的值,浪费性能的

删除缓存优点:简单、成本低,容易开发;缺点:会造成一次cache miss

如果更新缓存开销较小并且读多写少,基本不会有写并发的时候可以才用更新缓存,否则通用做法还是删除缓存。


总结

方案 问题 问题出现概率 推荐程度
更新缓存 -> 更新数据库 为了保证数据准确性,数据必须以数据库更新结果为准,所以该方案绝不可行 不推荐
更新数据库 -> 更新缓存 并发更新数据库场景下,会将脏数据刷到缓存 并发写场景,概率一般 写请求较多时会出现不一致问题,不推荐使用。
删除缓存 -> 更新数据库 更新数据库之前,若有查询请求,会将脏数据刷到缓存 并发读场景,概率较大 读请求较多时会出现不一致问题,不推荐使用
更新数据库 -> 删除缓存 在更新数据库之前有查询请求,并且缓存失效了,会查询数据库,然后更新缓存。如果在查询数据库和更新缓存之间进行了数据库更新的操作,那么就会把脏数据刷到缓存 并发读场景&读操作慢于写操作,概率最小 读操作比写操作更慢的情况较少,相比于其他方式出错的概率小一些。勉强推荐。


推荐方案

延迟双删

采用更新前后双删除缓存策略

public void write(String key,Object data){
  redis.del(key);
     db.update(data);
     Thread.sleep(1000);
     redis.del(key);
 }
  • 先淘汰缓存
  • 再写数据库
  • 休眠1秒,再次淘汰缓存

大家应该评估自己的项目的读数据业务逻辑的耗时。然后写数据的休眠时间则在读数据业务逻辑的耗时基础上即可。

这么做的目的,就是确保读请求结束,写请求可以删除读请求造成的缓存脏数据。

问题及解法:

1、同步删除,吞吐量降低如何处理

将第二次删除作为异步的,提交一个延迟的执行任务

2、解决删除失败的方式:

添加重试机制,例如:将删除失败的key,写入消息队列;但对业务耦合有些严重;

延时工具可以选择:

最普通的阻塞Thread.currentThread().sleep(1000);

Jdk调度线程池,quartz定时任务,利用jdk自带的delayQueue,netty的HashWheelTimer,Rabbitmq的延时队列,等等


实际场景

我们有个商品中心的场景,是读多写少的服务,并且写数据会发送MQ通知下游拿数据,这样就需要严格保证缓存和数据库的一致性,需要提供高可靠的系统服务能力。


写缓存策略

  1. 缓存key设置失效时间
  2. 先DB操作,再缓存失效
  3. 写操作都标记key(美团中间件)强制走主库
  4. 接入美团中间件监听binlog(美团中间件)变化的数据在进行兜底,再删除缓存


读缓存策略

  1. 先判断是否走主库
  2. 如果走主库,则使用标记(美团中间件)查主库
  3. 如果不是,则查看缓存中是否有数据
  4. 缓存中有数据,则使用缓存数据作为结果
  5. 如果没有,则查DB数据,再写数据到缓存


注意

关于缓存过期时间的问题

如果缓存设置了过期时间,那么上述的所有不一致情况都只是暂时的。

但是如果没有设置过期时间,那么不一致问题就只能等到下次更新数据时解决。

所以一定要设置缓存过期时间


最后

觉得有收获,希望帮忙点赞,转发下哈,谢谢,谢谢


相关实践学习
基于Redis实现在线游戏积分排行榜
本场景将介绍如何基于Redis数据库实现在线游戏中的游戏玩家积分排行榜功能。
云数据库 Redis 版使用教程
云数据库Redis版是兼容Redis协议标准的、提供持久化的内存数据库服务,基于高可靠双机热备架构及可无缝扩展的集群架构,满足高读写性能场景及容量需弹性变配的业务需求。 产品详情:https://www.aliyun.com/product/kvstore     ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库 ECS 实例和一台目标数据库 RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
相关文章
|
3月前
|
缓存 NoSQL Java
面试官:如何保证本地缓存的一致性?
面试官:如何保证本地缓存的一致性?
184 1
|
7月前
|
缓存 NoSQL 关系型数据库
Redis缓存与Mysql数据库的一致性问题解决
Redis缓存与Mysql数据库的一致性问题解决
62 0
|
3月前
|
缓存 算法 NoSQL
【分布式详解】一致性算法、全局唯一ID、分布式锁、分布式事务、 分布式缓存、分布式任务、分布式会话
分布式系统通过副本控制协议,使得从系统外部读取系统内部各个副本的数据在一定的约束条件下相同,称之为副本一致性(consistency)。副本一致性是针对分布式系统而言的,不是针对某一个副本而言。强一致性(strong consistency):任何时刻任何用户或节点都可以读到最近一次成功更新的副本数据。强一致性是程度最高的一致性要求,也是实践中最难以实现的一致性。单调一致性(monotonic consistency):任何时刻,任何用户一旦读到某个数据在某次更新后的值,这个用户不会再读到比这个值更旧的值。
401 0
|
3月前
|
缓存 NoSQL 关系型数据库
Redis系列-6.Redis缓存双写一致性问题(上)
Redis系列-6.Redis缓存双写一致性问题
77 0
|
2月前
|
缓存 NoSQL 关系型数据库
数据库缓存一致性学习笔记(一)
数据库缓存一致性学习笔记(一)
|
2月前
|
canal 缓存 中间件
缓存一致性 注意点
缓存一致性 注意点
23 0
|
6月前
|
消息中间件 缓存 Java
Java 最常见的面试题:怎么保证缓存和数据库数据的一致性?
Java 最常见的面试题:怎么保证缓存和数据库数据的一致性?
|
3月前
|
canal 缓存 关系型数据库
Springcloud Alibaba使用Canal将Mysql数据实时同步到Redis保证缓存的一致性
canal [kə'næl] ,译意为水道/管道/沟渠,主要用途是基于 MySQL 数据库增量日志解析,提供增量数据订阅和消费。其诞生的背景是早期阿里巴巴因为杭州和美国双机房部署,存在跨机房同步的业务需求,实现方式主要是基于业务 trigger 获取增量变更。从 2010 年开始,业务逐步尝试数据库日志解析获取增量变更进行同步,由此衍生出了大量的数据库增量订阅和消费业务。
|
3月前
|
缓存 NoSQL 关系型数据库
MySQL缓存策略(一致性问题、数据同步以及缓存故障)
MySQL缓存策略(一致性问题、数据同步以及缓存故障)
55 1
|
3月前
|
canal 缓存 NoSQL
Redis系列-6.Redis缓存双写一致性问题(下)
Redis系列-6.Redis缓存双写一致性问题
52 0

热门文章

最新文章