redis如何和数据库保持一致性

小吴顶呱呱2024-03-042024-03-16

1.针对读场景

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

那么针对此中数据不一致问题，就产生了以下两个疑问：

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

删缓存策略
- 优点：操作简单，直接将对应缓存删除即可
- 缺点：由于缓存被删除后，下次的读请求无法命中缓存，需回源db，将数据重新写入redis
更新缓存策略

优点：缓存命中率高，只要缓存进行了更新，后续的读请求不会出现缓存未命中(cache miss)的情况

缺点：在某些业务场景下，缓存更新的成本过大。且更新后的缓存不一定会被使用。

综合分析

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

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

举个例子来说，a表中的字段，1分钟更改了100次，如果采用更新缓存策略，则需要计算100次，哪怕1分钟内只有1次读请求；如果采用淘汰缓存策略，如果1分钟内只有1次请求，则只需要计算1次即可，开销大幅度降低。

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

异常情况

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

对于该种异常情况，提供两种解决思路：

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

异常情况1

异常情况2