我要评论前言
如果项目业务处于起步阶段，流量非常小，那无论是读请求还是写请求，直接操作数据库即可，这时架构模型是这样的：
但随着业务量的增长，项目业务请求量越来越大，这时如果每次都从数据库中读数据，那肯定会有性能问题。这个阶段通常的做法是，引入缓存来提高读性能，架构模型就变成了这样：
在实际开发过程中，缓存的使用频率是非常高的，只要使用缓存和数据库存储，就难免会出现双写时数据一致性的问题，就是 redis 缓存的数据和数据库中保存的数据出现不相同的现象。
如上图所示，大多数人的很多业务操作都是根据这个图来做缓存的，这样能有效减轻数据库压力。但是一旦设计到双写或者数据库和缓存更新等操作，就很容易出现数据一致性的问题。无论是先写数据库，在删除缓存，还是先删除缓存，在写入数据库，都会出现数据一致性的问题。例如：
- 先删除了redis缓存，但是因为其他什么原因还没来得及写入数据库，另外一个线程就来读取，发现缓存为空，则去数据库读取到之前的数据并写入缓存，此时缓存中为脏数据。
- 如果先写入了数据库，但是在缓存被删除前，写入数据库的线程因为其他原因被中断了，没有删除掉缓存，就也会出现数据不一致的情况。
总的来说，写和读在多数情况下都是并发的，不能绝对保证先后顺序，就会很容易出现缓存和数据库数据不一致的情况，那我们又该如何解决呢？
一、谈谈一致性
首先，我们先来看看有哪几种一致性的情况呢？
- 强一致性：如果你的项目对缓存的要求是强一致性的，那么请不要使用缓存。这种一致性级别是最符合用户直觉的，它要求系统写入什么，读出来的也会是什么，用户体验好，但实现起来往往对系统的性能影响大。读请求和写请求会串行化，串到一个内存队列里去，这样会大大增加系统的处理效率，吞吐量也会大大降低。
- 弱一致性：这种一致性级别约束了系统在写入成功后，不承诺立即可以读到写入的值，也不承诺多久之后数据能够达到一致，但会尽可能地保证到某个时间级别（比如秒级别）后，数据能够达到一致状态。
- 最终一致性：最终一致性是弱一致性的一个特例，系统会保证在一定时间内，能够达到一个数据一致的状态。这里之所以将最终一致性单独提出来，是因为它是弱一致性中非常推崇的一种一致性模型，也是业界在大型分布式系统的数据一致性上比较推崇的模型。一般情况下，高可用只确保最终一致性，不确保强一致性。
二、 情景分析
2.1 针对读场景
a请求查询数据，如果命中缓存，那么直接取缓存数据返回即可。如果请求中不存在，数据库中存在，那么直接取数据库数据返回，然后将数据同步到redis中。不会存在数据不一致的情况。
在高并发的情况下，a请求和b请求一起访问某条数据，如果缓存中数据存在，直接返回即可，如果不存在，直接取数据库数据返回即可。无论a请求b请求谁先谁后，本质上没有对数据进行修改，数据本身没变，只是从缓存中取还是从数据库中取的问题，因此不会存在数据不一致的情况。
因此，单独的读场景是不会造成redis与数据库缓存不一致的情况，因此我们不用关心这种情况。
2.2 针对写场景
如果该数据在缓存中不存在，那么直接修改数据库中的数据即可，不会存在数据不一致的情况。
如果该数据在缓存中和数据库中都存在，那么就需要既修改缓存中的数据又修改数据库中的数据。如果写数据库的值与更新到缓存值是一样的，可以马上更新缓存；如果写数据库的值与更新缓存的值不一致，在高并发的场景下，还存在先后关系，这就会导致数据不一致的问题。例如：
- 当更新数据时，如更新某商品的库存，当前商品的库存是100，现在要更新为99，先更新数据库更改成99，然后删除缓存，发现删除缓存失败了，这意味着数据库存的是99，而缓存是100，这导致数据库和缓存不一致。
- 在高并发的情况下，如果当删除完缓存的时候，这时去更新数据库，但还没有更新完，另外一个请求来查询数据，发现缓存里没有，就去数据库里查，还是以上面商品库存为例，如果数据库中产品的库存是100，那么查询到的库存是100，然后插入缓存，插入完缓存后，原来那个更新数据库的线程把数据库更新为了99，导致数据库与缓存不一致的情况。
三、同步策略
想要保证缓存与数据库的双写一致，一共有4种方式，即4种同步策略：
从这4种同步策略中，我们需要作出比较的是：更新缓存与删除缓存哪种方式更合适？应该先操作数据库还是先操作缓存？
3.1 先更新缓存，再更新数据库
这个方案我们一般不考虑。原因是当数据同步时，更新 redis 缓存成功，但更新数据库出现异常时，会导致 redis 缓存数据与数据库数据完全不一致，而且这很难察觉，因为 redis 缓存中的数据一直都存在。
只要缓存进行了更新，后续的读请求基本上就不会出现缓存未命中的情况。但在某些业务场景下，更新数据的成本较大，并不是单纯将数据的数据查询出来丢到缓存中即可，而是需要连接很多张表组装对应数据存入缓存中，并且可能存在更新后，该数据并不会被使用到的情况。
3.2 先更新数据库，再更新缓存
这个方案我们一般也是不考虑。原因是当数据同步时，数据库更新成功，但 redis 缓存更新失败，那么此时数据库中是最新值，redis 缓存中是旧值。之后的应用系统的读请求读到的都是 redis 缓存中旧数据。只有当 redis 缓存数据失效后，才能从数据库中重新获得正确的值。
该方案还存在并发引发的一致性问题，假设同时有两个线程进行数据更新操作，如下图所示：
从上图可以看到，线程1虽然先于线程2发生，但线程2操作数据库和缓存的时间，却要比线程1的时间短，执行时序发生错乱，最终这条数据结果是不符合预期的。如果是写多读少的场景，采用这种方案就会导致，数据压根还没读到，缓存就被频繁的更新，浪费性能。
3.3 先删除缓存，后更新数据库
这种方案只是尽可能保证一致性而已，极端情况下，还是有可能发生数据不一致问题，原因是当数据同步时，如果删除 redis 缓存失败，更新数据库成功，那么此时数据库中是最新值，redis 缓存中是旧值。之后的应用系统的读请求读到的都是 redis 缓存中旧数据。只有当 redis 缓存数据失效后，才能从数据库中重新获得正确的值。由于缓存被删除，下次查询无法命中缓存，需要在查询后将数据写入缓存，增加查询逻辑。同时在高并发的情况下，同一时间大量请求访问该条数据，第一条查询请求还未完成写入缓存操作时，这种情况，大量查询请求都会打到数据库，加大数据库压力。
该方案还存在并发引发的一致性问题，假设同时有两个线程进行数据更新操作，如下图所示。当缓存被线程一删除后，如果此时有新的读请求（线程二）发生，由于缓存已经被删除，这个读请求（线程二）将会去从数据库查询。如果此时线程一还没有修改完数据库，线程二从数据库读的数据仍然是旧值，同时线程二将读的旧值写入到缓存。线程一完成后，数据库变为新值，而缓存还是旧值。
从上图可见，先删除 redis 缓存，后更新数据库，当发生读/写并发时，还是存在数据不一致的情况。如何解决呢？最简单的解决办法就是延时双删策略：先淘汰缓存、再写数据库、休眠后再次淘汰缓存。这样做的目的，就是确保读请求结束，写请求可以删除读请求造成的缓存脏数据。
public void deleteredisdata(userinfo userinfo){
// 删除redis中的缓存数据
jedis.del(userinfo);
// 更新mysql数据库数据
userinfodao.update(userinfo);
try {
timeunit.seconds.sleep(2);
} catch(exception exp){
exp.printstacktrace();
}
// 删除redis中的缓存数据
jedis.del(userinfo);
}
延时双删就能彻底解决不一致吗？当然不一定来。首先，我们评估的延时时间并不能完全代表实际运行过程中的耗时，运行过程如果因为系统压力过大，我们评估的耗时就是不准确，仍然会导致数据不一致的出现。其次，延时双删虽然在保证事务提交完以后再进行删除缓存，但是如果使用的是mysql的读写分离的机构，主从同步之间其实也会有时间差。
3.4 先更新数据库，后删除缓存
实际使用中，建议采用这种方案。当然，这种方案其实一样也可能有失败的情况。
当数据同步时，如果更新数据库成功，而删除 redis 缓存失败，那么此时数据库中是最新值，redis 缓存中是旧值。之后的应用系统的读请求读到的都是 redis 缓存中旧数据。只有当 redis 缓存数据失效后，才能从数据库中重新获得正确的值。读的时候，先读缓存，缓存没有的话，就读数据库，然后取出数据后放入缓存，同时返回响应。更新的时候，先更新数据库，然后再删除缓存。
该方案还存在并发引发的一致性问题，假设同时有两个线程进行数据更新操作，如下图所示。当数据库的数据被更新后，如果此时缓存还没有被删除，那么缓存中的数据仍然是旧值。如果此时有新的读请求（查询数据）发生，由于缓存中的数据是旧值，这个读请求将会获取到旧值。当缓存刚好失效，这时有请求来读缓存（线程一），未命中缓存，然后到数据库中读取，在要写入缓存时，线程二来修改了数据库，而线程一写入缓存的是旧的数据，导致了数据的不一致。
四、解决办法
当我们在应用中同时使用mysql和redis时，如何保证两者的数据一致性呢？下面就来分享几种实用的解决方案。
4.1 双写一致性
最直接的办法就是在业务代码中同时对mysql和redis进行更新。通常我们会先更新mysql，然后再更新redis。
// 更新mysql
usermapper.update(user);
// 更新redis
redistemplate.opsforvalue().set("user_" + user.getid(), user);
这种方式最大的问题就是在于网络故障或者程序异常的情况下，可能会导致mysql和redis中的数据不一致。因此，我们需要额外的手段来检测和修复数据不一致的情况。
4.2 异步更新(异步通知)
在更新数据库数据时，同时发送一个异步通知给redis，让redis知道数据库数据已经更新，需要更新缓存中的数据。这个过程是异步的，不会阻塞数据库的更新操作。当redis收到异步通知后，会立即删除缓存中对应的数据，确保缓存中没有旧数据。这样，即使在这个过程中有新的读请求发生，也不会读取到旧数据。等到数据库更新完成后，redis再次从数据库中读取最新的数据并缓存起来。
// 更新mysql
usermapper.update(user);
// 发送消息
rabbittemplate.convertandsend("updateuser", user.getid());
/**
* 然后在消息消费者中更新redis。
*/
@rabbitlistener(queues = "updateuser")
public void updateuser(string userid) {
user user = usermapper.selectbyid(userid);
redistemplate.opsforvalue().set(redistemplate.opsforvalue().set("user_" + user.getid(), user);
}
这种异步通知的方式，可以确保redis中的数据与数据库中的数据保持一致，避免出现数据不一致的情况。这种方案可以降低数据不一致的风险，但仍然无法完全避免。因为消息队列本身也可能因为各种原因丢失消息。
4.3 使用redis的事务支持
redis提供了事务（transaction）支持，可以将一系列的操作作为一个原子操作执行。我们可以利用redis的事务来实现mysql和redis的原子更新。
redistemplate.execute(new sessioncallback<object>(){
@0verridepublic object execute(redisoperations operations) throws dataaccessexception {
// 开启事务
operations.multi();
// 更新mysql
usermapper.update(user);
// 更新redis
operations.opsforvalue().set("user_" + user.getid(),user);
// 执行事务
operations.exec();
return null;
}
});
使用redis事务可以确保mysql和redis的更新在同一事务中执行，避免了中间出现不一致的情况。但需要注意的是，redis的事务并非严格的acid事务，可能存在部分成功的情况。
4.4 用 redisson 实现读锁和写锁
redisson 是一个基于 redis 的分布式 java 对象存储和缓存框架，它提供了丰富的功能和 api 来操作 redis 数据库，其中包括了读写锁的支持。读写锁是一种常用的并发控制机制，它允许多个线程同时读取共享资源，但在写操作时互斥，只允许一个线程进行写操作。使用 redisson 的读写锁方法：
- 获取读锁：通过 redisson 的 rreadwritelock 对象的 readlock() 方法获取读锁。在获取读锁后，可以并发读取共享资源，不会阻塞其他获取读锁的线程。
- 获取写锁：通过 redisson 的 rreadwritelock 对象的 writelock() 方法获取写锁。在获取写锁后，其他获取读锁和写锁的线程将被阻塞，只有当前线程能够进行写操作。
- 释放锁：使用完读锁或写锁后，应该及时调用 unlock() 方法释放锁，以便其他线程可以获取锁并进行操作。在 redisson 中，读锁和写锁都继承自锁对象 rlock，因此可以使用 rlock 的 unlock() 方法来释放锁。
下面是一个使用 redisson 读写锁的示例，通过 redisson 的 rreadwritelock 对象获取读锁和写锁，并在需要的代码段中进行相应的操作。执行完操作后，使用 unlock() 方法释放锁，最后关闭 redisson 客户端。
import org.redisson.redisson;
import org.redisson.api.rlock;
import org.redisson.api.redissonclient;
import org.redisson.config.config;
public class redissonreadwritelockexample {
public static void main(string[] args) {
// 创建 redisson 客户端
config config = new config();
config.usesingleserver().setaddress("redis://127.0.0.1:6379");
redissonclient redisson = redisson.create(config);
// 获取读写锁
rreadwritelock rwlock = redisson.getreadwritelock("mylock");
rlock readlock = rwlock.readlock();
rlock writelock = rwlock.writelock();
try {
// 获取读锁并进行读操作
readlock.lock();
// 读取共享资源
// 获取写锁并进行写操作
writelock.lock();
// 写入共享资源
} finally {
// 释放锁
writelock.unlock();
readlock.unlock();
}
// 关闭 redisson 客户端
redisson.shutdown();
}
}
五、结语
综上所述，我们提供了更全面的mysql与redis数据一致性解决方案。根据具体的业务需求和系统环境，选择合适的方案可以提高数据一致性的可靠性。然而，每种方案都有其优缺点和适用场景，需要综合考虑权衡。
对于并发几率很小的数据(如个人维度的订单数据、用户数据等)，这种几乎不用考虑这个问题，很少会发生缓存不一致，可以给缓存数据加上过期时间，每隔一段时间触发读的主动更新即可。就算并发很高，如果业务上能容忍短时间的缓存数据不一致(如商品名称，商品分类菜单等)，缓存加上过期时间依然可以解决大部分业务对于缓存的要求。
到此这篇关于redis缓存和数据库的数据一致性的问题解决的文章就介绍到这了,更多相关redis缓存和数据库的数据一致性内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网！
发表评论