如何保障MySQL和redis缓存的一致性

最新推荐文章于 2024-04-13 10:41:37 发布

住手丶让我来

最新推荐文章于 2024-04-13 10:41:37 发布

阅读量469

点赞数 1

分类专栏： MySQL 文章标签：数据库

本文链接：https://blog.csdn.net/weixin_42146366/article/details/108873971

版权

20 篇文章 0 订阅

订阅专栏

本文分析了数据库和Redis缓存一致性问题，讨论了读写场景中的解决方案，并比较了淘汰缓存与更新缓存策略的优劣。重点关注了数据更新顺序问题，提出延时双删和异步更新两种应对策略，以及在先写后读策略中可能产生的短暂数据不一致及其解决办法。

摘要由CSDN通过智能技术生成

一、问题分析

众所周知，数据库是把数据存储在磁盘上，访问时需要进行IO操作，在请求量小的情况下，耗时还比较低。但随着数据量的增大，访问量的集中，整个数据库负担加重，响应就会变慢，请求延时上升。进而导致用户侧的等待时间变长，很大程度上影响了用户体验。

为了解决这一问题，在整个请求链路上就引入了缓存的策略，将数据库中的数据copy一份到redis缓存（毕竟可是号称单机抗10w qps）。由于redis的数据是直接存在内存中，因此读写数据速度提升，整体请求响应速度也得到了提高。

但是这样一来，数据就存在了两个地方：缓存redis和数据库db中，不可避免出现redis和db中数据的一致性问题。

如果redis中存在用户所需数据，直接返回即可；如果不存在，则试图从db中读取数据，读取完成后，将该数据更新到redis中，避免下次再次查询或其他用户查询时，仍从db读取。
在高并发场景下，两次请求同时请求redis，发现数据并不存在后，都会从db中加载数据，然后再重新将数据写入redis，无论两次请求的写操作谁先谁后，数据本身是一样的，只不过额外进行了一次数据写覆盖。因此不会产生数据不一致的问题。

如果redis中本身不存在缓存数据，则直接修改db中的数据即可，不会产生数据不一致问题。
如果redis中已存在缓存数据，则需要同时修改db和redis中的数据，但是二者修改操作的执行必然存在先后顺序。在高并发的场景下，就有可能产生数据不一致的情况。

由于redis中的数据可有可无，那么当数据发生变化时，是对redis中的数据进行修改，还是直接删除对应的redis，然后通过后续的读请求再回源db，将数据重新写入redis呢？
redis和db的数据写操作的顺序问题，是先更新redis，还是先更新db？

其实业界一般采用的都是缓存淘汰策略，而非缓存更新策略。原因有三：

大多数情况下，redis缓存中的数据并不是完全copy
db中的数据，而是将db中多张表的数据进行了重新计算，筛选后更新到redis。如果在db某一张表的数据发生了变化的情况下，需要同步重新计算redis中的值，成本过高。
缓存更新后的新值，无法保证一定会有读请求命中，如果一直没有请求命中该部分冷数据，其实是产生了一定的资源浪费（计算成本+存储成本）。
相较于淘汰缓存策略中，仅有一次读请求cache miss的结果来说，淘汰缓存策略的缺点完全可以容忍。

注意：以下的方案讨论都是基于redis淘汰缓存操作以及数据库更新操作保证成功（可通过重试机制解决）的情况下，高并发的业务场景中的解决方案。

A请求进行写操作，先淘汰缓存。
B请求进行读操作，由于A请求已将缓存淘汰，B请求没有在redis中发现所需数据，因此从数据库中读取数据，并更新缓存到redis中。注意，此时redis中被更新的依然是老数据，A请求的数据库更新操作尚未完成。
A请求进行数据库更新操作。此时，数据库中是新数据，redis缓存中是老数据，产生了数据不一致的问题。且该不一致会一直持续到缓存自然失效或者下次的更新操作。

异步更新缓存

延时双删

A请求进行写操作，先淘汰缓存。
B请求进行读操作，由于A请求已将缓存淘汰，B请求没有在redis中发现所需数据，因此从数据库中读取数据，并更新缓存到redis中。注意，此时redis中被更新的依然是老数据，A请求的数据库更新操作尚未完成。假设该步骤耗时N秒。
A请求进行数据库更新操作。
由于此时redis中写入了老数据，因此A请求在休眠M秒后（M略大于N），再次对redis进行淘汰缓存操作。
该方案虽然解决了数据不一致的问题，但是由于请求A在更新完数据库之后，需要休眠M秒再次淘汰缓存，一定程度上影响了数据更新操作的吞吐量。可以尝试将等待M秒更新redis的操作放到另一个单独的线程（比如消息队列+重试机制），可以有效缓解吞吐量降低的问题。