06.分布式解决方案-canal解决mysql与redis数据一致性问题
1.mysql与redis如何实现数据同步问题?
2.什么是缓存延迟双删策略
3.为什么不建议使用延迟双删
4.先删除缓存,在更新db还是?先更新db在删除缓存?
5.什么是双写一致性协议
6.并发的情况下如何保证双写一致性问题
7.分布式锁如何解决双写一致性问题
8.mysql行锁机制如何解决双写一致性问题
9.为何说分布式情况下强一致性几乎很难实现
20点25准时开始
概述
作者:余胜军 微信:yushengjun644 QQ644064065
该内容为原创,未经过允许的情况下 请勿转载!
在高并发的情况下,我们会使用Redis缓存减轻数据库访问压力,先查询缓存,如果缓存中没有数据在查询数据库,将数据库的数据在缓存到Redis中,如果db数据发生了更新,需要同步到Redis中,同步的过程中需要保证:MySQL与Redis数据一致性问题,mysql与redis数据同步过程中,需要花费短暂的时间,所以会产生短暂的延迟,属于正常现象。
一致性情况:如果缓存中有数据,需要与MySQL中数据保持一致性;
String value=getRedisKey(key);//先查询Redis 如果redis中有数据,则不会查询db
if(!StringUtils.isEmpty(value)){
return value;
}
// 如果redis缓存没有数据,则查询db,将db中的数据放入缓存中。
UserDo userDb=userMapper.getUser(userId);
if(userDb==null){
return null;
}
RedisUtils.set(key,userDb); // 将db数据放入到缓存中
return userDb;
mysql与redis数据如何保证一致性?
延迟双删策略
先删除缓存,在更新DB
无并发的情况
伪代码:
deleteMayiktRedis(key);// 先删除缓存
updateDB(user);// 更新db中的数据
1.如果A请求删除缓存成功,但是更新DB失败呢,导致Redis与mysql数据一致性,另外请求过来有从新查询db数据老的数据放入到缓存中;
解决办法:
1.采用MQ异步的形式,先删除缓存在更新db中的数据,MQ消费者如果消费失败了,MQ服务器端自动
触发重试策略,保证该msg必须消费成功。
高并发的情况
1.t1线程先删除缓存;
2.t2线程读取缓存为null,同步db数据到缓存中;
3.t1线程更新db中的数据;
4.t3线程查询缓存中数据是旧数据;
如何解决该问题:延迟双删策略
t1线程更新完DB后,让它sleep一段时间,再删除缓存 ;
---------延迟双删 谁提出的?不靠谱?
为何要sleep一段时间,再删除缓存?
T2线程如果读取到DB旧的数据,再把旧的数据写入缓存,然后,T1线程延迟再进行删除。
所以,T1 sleep的时间,就需要大于T2读取数据再写入缓存的时间。
延迟的时间如何确定?
在业务程序运行时,统计业务逻辑执行读数据和写缓存的操作时间,以此为基础来进行估算。因为这个方案会在第一次删除缓存值后,延迟一段时间再次进行删除,所以称为“延迟双删”。----不推荐大家使用延迟双删
deleteMayiktRedis(key);// 先删除缓存
updateMayiktDB(user);// 更新db中的数据
Thread.sleep(u);// 延迟一段时间,在删除该缓存key
deleteMayiktRedis(key);// 先删除缓存
先更新DB,在删除缓存
t1线程 先更新db;
t2线程查询命中缓存 返回旧的数据;
t1线程在删除缓存
假设t1线程更新完db,预计5毫秒删除完缓存key 在5毫秒内 其他线程查询缓存结果还是为旧的数据,但是
5毫秒后查询缓存结果是为空,在从新将db最新的结果同步到Redis中。
分布式数据同步的过程中,延迟是非常正常的,所以该情况发生的延迟对业务的影响其实很小。
但是如果发生了,删除缓存失败呢?
1.不断重试----如果是在http协议接口中 会导致接口响应变慢 调用该接口 会发生响应超时—
2.或者通过mq异步的形式同步
确保缓存删除成功。
updateMayiktDB(user);// 更新db中的数据
deleteMayiktRedis(key);// 先删除缓存
方案如何选择?
绝大多数场景都会将Redis作为只读缓存:
1.先删除缓存值再更新数据库—更新db完成之后 延迟双删策略 延迟时间多久
是很难控制的。
2.也可以先更新数据库再异步 mq消费者删除缓存;----推荐
3.因为先更新db,在删除缓存,其他线程在读过程中只是短暂读取到数据是旧数据,只要及时的将该缓存key删除,其他线程就可以读取到最新的数据。
4.而先删除缓存,在更新db 有可能将旧的数据缓存到Redis中,导致其他线程一直查询的数据是为旧的数据,
需要考虑延迟双删问题,延迟双删时间不是很好控制。
所以推荐使用 先更新,在删除缓存。
双写一致性协议原理
什么是双写?
updateDB
updateRedis
直接更新 Cache
1.更新完db后,同步更新Redis; 更新db操作与更新redis操作 是一样的 不是 直接删除Redis缓存key 俗称:双写
例如
1.updateMayiktDB(user);
2.updateMayiktRedis(user);
1.deleteMayiktDB(user);
2.deleteMayiktRedis(user);
1.insertMayiktDB(user);
2.insertMayiktRedis(user);
先更新完db后,在同步到redis的过程中会存在短暂的延迟, 影响的业务其实很小。
但是如果在并发的情况下做双写会存在同步Redis数据不一致问题。
并发情况下如何保证双写一致性
概述:
在多个线程同时修改db和redis;
在db 层面 mysql 行锁机制 多个线程 同时修改同一行数据
最终只会有一个线程能够修改成功;在底层存储引擎层面
保证数据线程安全性问题。
例如:
t1 先执行 updatedb name=xiaowei
t2 在执行 updatedb name=xiaojun
最终db层面 name=xiaojun
t1和t2同时更新Redis
t2线程 先执行 update redis name=xiaojun
在执行t1 线程 update redis name=xiaowei
db层面 name=xiaojun Redis name=xiaowei
如何解决?锁的形式解决
1.分布式锁的形式 ----不推荐 效率很低 最终 代码执行 变成单线程。
2.通过mysql 行锁形式
t1和t2线程 同时对db数据做修改操作,同时需要更新redis缓存。
但是在同时更新redis缓存过程中 ,会存在顺序执行问题,导致数据不一致。
begin;
t1线程
updatemayiktDb(name)---mayikt
updatemayiktRedis(name)---mayikt
commit/rollback
begin;
t2线程
updatemayiktDb(name)---xiaojun
updatemayiktRedis(name)---xiaojun
commit/rollback
解决办法:
1.分布式锁解决多个线程同时执行双写业务逻辑,最终只会有一个获取到分布式锁线程才可以执行,没有获取到分布式锁线程则阻塞等待,这样确保线程执行双写 不会被其他线程干扰,但是效率非常低;
2.mysql 行锁实现 ,多个线程同时获取行锁,最终只会有一个线程获取行锁成功,
获取行锁成功的线程 如果更新Redis 成功,就可以提交事务,如果更新redis 失败
可以采用重试策略,重试多次更新到redis还是失败的话,直接回滚事务,同时释放行锁,行锁-----提交或者回滚事务。 但是效率非常低;不推荐
mysql 数据同步到Redis----该网络传输的过程中 需要花费时间
redis 与mysql 如何保证数据一致性问题
1.先删除缓存,在更新db-----延迟双删的 不推荐
2.先更新db,在删除缓存----mq 确保删除缓存 一定成功
3.双写一致性协议 并发的情况下 结合锁的形式 避免
数据同步到redis发生了不一致。
4.canal+kafka+消息顺序一致性—
推荐mq异步 双写 没有锁的竞争效率比较高 —延迟问题
更多推荐
所有评论(0)