大前提

1. 如果要求强一致性，就不要使用redis，使用redis代表可以接受最终一致性
2. 使用redis作为缓存，必须设置过期时间，原因: 即使程序有问题，不能保证redis的最终一致性，key也会自己失效

保证redis与mysql数据最终一致性，有以下几种方案

方案一

先更新redis，再更新mysql
流程图

image.png

最后mysql是请求1的数据，redis是请求2的数据，不能保证最终一致性

方案二

先更新mysql，再更新redis
流程图

image.png

最后mysql是请求2的数据，redis是请求1的数据，不能保证最终一致性

方案三

先删redis，再更新mysql
流程图

image.png

最后mysql是新数据，redis是旧数据，不能保证最终一致性

方案四

先更新mysql，再删redis
流程图

image.png

最后mysql是新数据，redis是旧数据

方案五

延迟删除: 先更新mysql，然后sleep一段时间，再删除redis
流程图

image.png

sleep时间，由业务侧决定，最好是大于查询接口的耗时。

方案六

方案五的问题是: 更新mysql后，删除redis之前，查询请求从redis查到的是旧数据，虽然可以保证最终一致性，但是查到旧数据的时间较长。

基于方案五的问题，方案六提出了延迟双删: 先删redis，然后更新mysql，然后sleep一段时间，再删除redis。
本方案可以让用户更早查询到新数据。

image.png

方案六看起来是所有方案中最优的，但其实还是有问题，比如下面的情况（出现概率极低），如果确实发生了这种情况，只能等key到达过期时间自己失效，或者引入mq等中间件对删除redis失败做重试。

image.png

最后，友情提示一下，这个问题是面试高频题，但是面试没法画图，很难描述清楚各种场景，可以用下面的表达方式

请求1: 更新redis--------------------------------------更新mysql
请求2: -------------更新redis--------------更新mysql
最后redis是请求2的数据，mysql是请求1的数据