一,使用方案
在使用redis作为缓存的场景下,我们一般使用流程如下
二,更新数据场景
我们此时修改个某条数据,如何保证mysql数据库和redis缓存中的数据一致呢?
按照常规思路有四种办法,1.先更新mysql数据,再更新缓存数据 2.先更新缓存数据,再更新mysql数据
3.先删除缓存,再更新mysql数据 4.先更新mysql数据,再删除缓存 。
这四种方法各有各的弊端,并不能完全保证数据一致性,采用“先写 MySQL,再删除 Redis”的策略,这种情况虽然也会存在两者不一致,但是需要满足的条件有点苛刻,所以是满足实时性条件下,能尽量满足一致性的最优解。对于不是强一致性要求的业务,可以容忍。(什么情况下不能容忍呢,比如秒杀业务、库存服务等。)
为什么采用删除缓存而不是更新缓存,是因为高并发下产生脏数据的要求要比更新缓存的要求更多,也就是删除缓存产生脏数据的概率更小一些。
那么问题又来了,在高并发的情况下
采用先删除缓存,再更新数据库
- 请求A来了,删除缓存
- 请求A更新数据库,发生卡顿,同时来了请求B
- 请求B发现没有缓存,就从数据库查询了数据,并生成了缓存
- 此时请求A卡顿结束,更新了数据库
这个情况下,缓存中的就是脏数据。我们采用延时双删来解决
那么问题又来了,第二次删除缓存失败了怎么办?看下面 - 先更新数据库,再删除缓存
如果删除缓存失败,怎么保证数据一致性?
1.使用重试机制,可以直接在接口中重试,但是比较耗费性能
2.使用异步队列重试
3.使用rabbitmq消息中间件来处理
当用户操作写完数据库,但删除缓存失败了,产生一条mq消息,发送给mq服务器。
mq消费者读取mq消息,重试5次删除缓存。如果其中有任意一次成功了,则返回成功。如果重试了5次,还是失败,则写入死信队列中。
当然在该方案中,删除缓存可以完全走异步。即用户的写操作,在写完数据库之后,不用立刻删除一次缓存。而直接发送mq消息,到mq服务器,然后有mq消费者全权负责删除缓存的任务。
因为mq的实时性还是比较高的,因此改良后的方案也是一种不错的选择。
总结:以上方法只能保证最终一致性,不能保证强一致性