后台-插件-广告管理-首页/栏目/内容广告位一(PC) |
后台-插件-广告管理-首页/栏目/内容广告位一(手机) |
前言
MySQL和Redis数据一致性算是个很经典的问题,在之前也看到过很多相关的文章,最近心血来潮,想把一致性问题的解决方案和存在问题都总结一下。
不推荐方案
1 先更新MySQL,再更新Redis。
如上图有两个请求要同时进行更新操作,在并发情况下,B请求虽然更新时间晚于A请求,但是可能因为网络延迟问题,导致本来A请求要先更新Redis的操作晚于B请求更新Redis的操作,最终导致了MySQL出现数据不一致。
2 先更新Redis,在更新MySQL。
这种情况其实等同于第一种情况。
3 先删除Redis缓存,再更新MySQL。
A请求对数据的更新操作晚于请求B的读取操作,导致B请求将数据库的旧值又写回缓存,删除缓存在这种情况下没有意义。
推荐方案
1 先删除Redis缓存,再更新MySQL,再删一次Redis缓存(延迟双删)
在第三种情况中,出现了删除缓存后被其他请求更新为旧值的情况,那么在这种情况下,再删除一遍缓存不就可以解决问题了。这里第二次删除缓存的时间必须在B请求回写旧值之后,所以要社招好第二次删除缓存的等待时间,根据业务实际耗时来定,假设B请求回写缓存要300ms,那么A请求可以设置等待500ms再进行缓存删除。
但是上面这种情况也会出现问题,比如延迟双删的时候删除缓存失败怎么办。
这个时候可以借助MQ重试机制。如下图:
将删除的请求放到MQ队列里面,然后系统再从MQ里面取出删除请求的操作,由于MQ支持失败重试,删除失败后会继续投递消息。
2 先更新MySQL,再删除Redis缓存。
在上面这种情况下,请求B出现了读取了一次旧值,如果对于业务是一致性要求没那么强的话(比如秒杀,减库存),这种方案也是可以的,误差范围是可以接收的,只存在这么一次数值是旧的情况。
当然还有特殊情况如下:
当B请求先查询Redis,这个时候redis刚好缓存失效,B请求就会去MySQL查询旧值,后续B请求回写旧值的请求又晚于A请求删除缓存的请求,导致缓存里面放的是旧值。
但是这种情况出现需要 同时满足以下两个条件:
(1)缓存刚好失效
(2)读请求回写缓存的时间晚于写请求回写缓存的时间
上述两个条件同时成立的概率是极小的,综上来说,这种方案还是不错的,复杂度也不高,但同时也是可能存在删除缓存失败的特殊情况导致误差。
3 先更新MySQL,通过 Binlog,异步更新 Redis
A请求更新完MySQL,借助Canal进行监听并把相关的修改记录推送到MQ,MQ经过消费系统拉取消息对Redis进行更新,如果在Redis更新之前,有新的读请求,依然会导致数据不一致性的问题,但是这种方案能够实现最终一致性。
在这里Canal作为一个组件,监听binlog和发送消息到MQ都由Canal完成。
方案总结
前三种方案都是不推荐使用的。对于推荐使用的方案,从实时性和技术复杂度来说,先写数据库再删除缓存是比较好的选择。如果要确保最终一致性的话,可以用binlog异步更新缓存的方案。