如何保证Redis与数据库的数据一致性 ゝ一纸荒年。 2024-03-27 11:41 20阅读 0赞 首先，分为两种场景： ## 一. 针对读场景： ## （1） A请求查询数据，如果命中缓存，那么直接取缓存数据返回即可。如果请求中不存在，数据库中存在，那么直接取数据库数据返回，然后将数据同步到Redis中。不会存在数据不一致的情况。 （2） 在高并发的情况下，A请求和B请求一起访问某条数据，如果缓存中数据存在，直接返回即可，如果不存在，直接取数据库数据返回即可。无论A请求B请求谁先谁后，本质上没有对数据进行修改，数据本身没变，只是从缓存中取还是从数据库中取的问题，因此不会存在数据不一致的情况。 **因此，单独的读场景是不会造成Redis与数据库缓存不一致的情况，因此我们不用关心这种情况。** ## 二. 针对写场景： ## （1） 如果该数据在缓存中不存在，那么直接修改数据库中的数据即可，不会存在数据不一致的情况。 **（2） 如果该数据在缓存中和数据库中都存在，那么就需要既修改缓存中的数据又修改数据库中的数据，而且在高并发的场景下，还存在修后关系，这就会导致数据不一致的问题。** ### 针对(2)的情况有两个疑问： ### **（1）是删除缓存数据，等待下次查询该数据时，缓存中没有直接去数据库中查询，同时添加到缓存中，还是更新缓存呢？ （2）更新缓存中的数据，是先更新缓存还是先更新数据库呢？** ### 关于疑问(1)有两个方案 ### #### 方案1：删除缓存 #### 优点：实现简单，不需要再更新数据库操作时在进行更新数据逻辑，直接删除对应缓存的key即可。 缺点：由于缓存被删除，下次查询无法命中缓存，需要在查询后将数据写入缓存，增加查询逻辑。同时在高并发的情况下，同一时间大量请求访问该条数据，第一条查询请求还未完成写入缓存操作时，这种情况，大量查询请求都会打到数据库，加大数据库压力。 #### 方案2：更新缓存 #### 优点：缓存命中率高，只要缓存进行了更新，后续的读请求就不会出现缓存未命中的情况。 缺点：在某些业务场景下，更新数据的成本较大，并不是单纯将数据的数据查询出来丢到缓存中即可，而是需要连接很多张表组装对应数据存入缓存中，并且可能存在更新后，该数据并不会被使用到的情况。 #### 综合分析 #### 在一般的业务中一般都采用缓存淘汰这种方案，而非缓存更新。因为： * 大多数情况下，redis缓存中的数据并不是完全复制数据库中的数据，而是将db中多张表的数据进行了重新计算，筛选后更新到redis。如果在db某一张表的数据发生了变化的情况下，需要同步重新计算redis中值的话，更新成本过高。 * 缓存更新后的新值，无法保证一定会有读请求命中，如果一直没有请求命中该部分冷数据，其实是产生了一定的资源浪费（计算成本+存储成本）。 * 相较于删除缓存方案来说，仅有一次读请求cache miss的结果来说，淘汰缓存策略的缺点完全可以容忍。 比如，A表中的字段，1分钟更改了100次，如果采用更新缓存策略，则需要计算100次，哪怕1分钟内只有1次读请求；如果采用淘汰缓存策略，如果1分钟内只有1次请求，则只需要计算1次即可，开销大幅度降低。 ### 关于疑问(2)有两个方案 ### #### 方案1：先更新缓存，后更新数据库 #### ##### 正常情况 ##### （1）A请求进行写操作，先淘汰缓存，再更新数据库 （2）B请求进行读操作，由于A请求已将缓存淘汰，B请求没有在redis中发现所需数据，因此从数据库中读取数据，并更新缓存到redis中 ##### 异常情况1 ##### **（1）A请求进行写操作，先淘汰缓存 （2）B请求进行读操作，由于A请求已将缓存淘汰，B请求没有在redis中发现所需数据，因此从数据库中读取数据，并更新缓存到redis中。注意，此时redis中被更新的依然是老数据，A请求的数据库更新操作尚未完成 （3）A请求进行数据库更新操作。此时，数据库中是新数据，redis缓存中是老数据，产生了数据不一致的问题。且该不一致会一直持续到缓存自然失效或者下次的更新操作** **对于该种异常情况，提供两种解决思路：** ###### 1.异步更新缓存 ###### ***（1）A请求进行写操作，先淘汰缓存 （2）B请求进行读操作，由于A请求已将缓存淘汰，B请求没有在redis中发现所需数据，因此从数据库中读取数据。注意，此时不向redis写入新的缓存策略 （3）A请求通过订阅数据库binlog，对redis缓存数据进行异步更新*** **该方案虽然解决了数据不一致的问题，但是在数据库更新操作完成前，所有的读请求都会直接打到数据库上，具有比较大的风险。** ###### 2.延时双删 ###### ***（1）A请求进行写操作，先淘汰缓存 （2）B请求进行读操作，由于A请求已将缓存淘汰，B请求没有在redis中发现所需数据，因此从数据库中读取数据，并更新缓存到redis中。注意，此时redis中被更新的依然是老数据，A请求的数据库更新操作尚未完成。假设该步骤耗时N秒 （3）A请求进行数据库更新操作。 （4）由于此时redis中写入了老数据，因此A请求在休眠M秒后（M略大于N），再次对redis进行淘汰缓存操作*** **该方案虽然解决了数据不一致的问题，但是由于请求A在更新完数据库之后，需要休眠M秒再次淘汰缓存，一定程度上影响了数据更新操作的吞吐量。可以尝试将等待M秒更新redis的操作放到另一个单独的线程（比如消息队列 + 重试机制）。可以有效缓解吞吐量降低的问题。** ##### 异常情况2 ##### **（1）A请求进行读操作，此时redis缓存中没有数据，因此直接从数据库中读取数据 （2）B请求进行写操作，先淘汰缓存，再更新数据库 （3）A请求进行将从数据库中读到的老数据，更新到redis。此时产生数据不一致问题。** **该种异常情况发生概率极低，一般读操作比写操作要快。如有担心，可以采用上述的延时删除策略** #### 方案2: 先更新数据库，后更新缓存 #### ##### 正常情况 ##### （1）A请求进行写操作，先更新数据库，再淘汰缓存 （2）B请求进行读操作，由于A请求已将缓存淘汰，B请求没有在redis中发现所需数据，因此从数据库中读取数据，并更新缓存到redis中 ##### 异常情况1 ##### **（1）A请求进行写操作，先更新数据库 （2）B请求进行读操作，由于A请求尚未淘汰缓存，B请求在redis中发现所需数据，因此直接返回老数据，产生了数据不一致的问题 （3）A请求淘汰缓存。 （4）C请求进行读操作，发现redis中没有数据，因此从数据库中读取新数据，并更新至缓存。数据不一致的问题解决。** **该场景下，数据最终一致，只是在高并发下产生了一小段时间的数据不一致。** ##### 异常情况2 ##### **（1）A请求进行读操作，此时redis缓存中没有数据，因此直接从数据库中读取数据 （2）B请求进行写操作，更新数据库，并将redis中缓存进行了淘汰（虽然此时redis中并没有任何的缓存） （3）A请求将从数据库中读到的老数据，更新到redis。此时产生数据不一致问题。** **该种异常情况发生概率极低，一般读操作比写操作要快。如有担心，可以采用上述的延时删除策略。** #### 总结 #### **方案1：先淘汰缓存，后更新数据库的策略，有可能导致长时间的数据不一致问题，可以通过延时双删 or 异步更新缓存策略进行解决。 方案2：先更新数据库，后更新缓存，有可能导致极短时间内的数据不一致，但是数据最终是一致的。**
还没有评论，来说两句吧...