掘地三尺搞定Redis与MySQL数据一致性问题(8)

这样子会出现缓存的是旧数据，在缓存过期之前无法读取到最数据。肖菜鸡本就被 98 号技师接单了，但是大堂经理却以为没人接待。
该方案 pass，因为第一步成功，第二步失败，会造成数据库是旧数据，缓存中没数据继续从数据库读取旧值写入缓存，造成数据不一致，还会多一次 cahche。
不论是异常情况还是高并发场景，会导致数据不一致。miss。

3.4 先更新数据库，再删缓存

经过前面的三个方案，全都被 pass 了，分析下最后的方案到底行不行。
按照「套路」，分别判断异常和高并发会造成什么问题。
该策略可以知道，在写数据库阶段失败的话就直返返回客户端异常，不需要执行缓存操作了。
所以第一步失败不会出现数据不一致的情况。

删缓存失败

重点在于第一步写最新数据到数据库成功，删除缓存失败怎么办？
可以把这两个操作放在一个事务中，当缓存删除失败，那就把写数据库回滚。
高并发场景下不合适，容易出现大事务，造成死锁问题。
如果不回滚，那就出现数据库是新数据，缓存还是旧数据，数据不一致了，咋办？
所以，我们要想办法让缓存删除成功，不然只能等到有效期失效那可不行。
使用重试机制。
比如重试三次，三次都失败则记录日志到数据库，使用分布式调度组件 xxl-job 等实现后续的处理。
在高并发的场景下，重试最好使用异步方式，比如发送消息到 mq 中间件，实现异步解耦。
亦或是利用 Canal 框架订阅 MySQL binlog 日志，监听对应的更新请求，执行删除对应缓存操作。

高并发场景

再来分析下高并发读写会有什么问题……

先写数据库后删缓存
98 号技师先下手为强，接下肖菜鸡的这笔生意，数据库执行 set 肖菜鸡的服务技师 = 98；还是网络卡顿了下，没来得及执行删除缓存操作。主管 Candy 向系统执行读请求，查下肖菜鸡有没有技师接待，发现缓存中有数据 肖菜鸡的服务技师 = 待定，直接返回信息给客户端，主管以为没人接待。原先 98 号技师接单，由于卡顿没删除缓存的操作现在执行删除成功。