先更新Mysql,再更新Redis,如果更新Redis失败,可能仍然不⼀致
先删除Redis缓存数据,再更新Mysql,再次查询的时候在将数据添加到缓存中
这种⽅案能解决1 ⽅案的问题,但是在⾼并发下性能较低,⽽且仍然会出现数据不⼀致的问题,
⽐如线程1删除了 Redis缓存数据,正在更新Mysql,
此时另外⼀个查询再查询,那么就会把Mysql中⽼数据⼜查到 Redis中使用MQ异步同步, 保证数据的最终一致性
我们项目中会根据业务情况 , 使用不同的方案来解决Redis和Mysql的一致性问题 :
对于一些一致性要求不高的场景 , 不做处理
例如 : 用户行为数据 , 我们没有做一致性保证 , 因为就算不一致产生的影响也很小
对于时效性数据 , 设置过期时间
例如 : 接口缓存数据 , 我们会设置缓存的过期时间为 60S , 那么可能会出现60S之内的数据不一致, 60S后缓存过期, 重新从数据库加载就一致了
对于一致性要求比较高但是时效性要求不那么高的场景 , 使用MQ不断发送消息完成数据同步直到成功为止
例如 : 首页广告数据 , 首页推荐数据
数据库数据发生修改----> 发送消息到MQ -----> 接收消息更新缓存
消息不丢失/重复消费 : 消息状态表/消息消费表
对于一致性和时效性要求都比较高的场景 , 使用分布式事务 , Seata的TCC模式
很少用