当前位置：首页 > article >正文

【redis-05】redis保证和mysql数据一致性

article 2024/10/7 14:00:55

redis系列整体栏目

内容	链接地址
【一】redis基本数据类型和使用场景	https://zhenghuisheng.blog.csdn.net/article/details/142406325
【二】redis的持久化机制和原理	https://zhenghuisheng.blog.csdn.net/article/details/142441756
【三】redis缓存穿透、缓存击穿、缓存雪崩	https://zhenghuisheng.blog.csdn.net/article/details/142577507
【四】redisson实现分布式锁实战和源码剖析	https://zhenghuisheng.blog.csdn.net/article/details/142646301
【五】redis保证和mysql数据一致性	https://zhenghuisheng.blog.csdn.net/article/details/142687101

如需转载，请输入：https://blog.csdn.net/zhenghuishengq/article/details/142687101

redis保证和mysql数据一致性

一，redis保证和mysql数据一致性
- 1，数据不一致原因
- - 1.1，更新缓存出现的问题
  - 1.2，删除缓存出现的问题
  - 1.3，理想情况
- 2，数据不一致解决方案
- - 2.1，延迟双删(不推荐)
  - 2.2，消息队列
  - 2.3，分布式锁
  - 2.4，canal同步

一，redis保证和mysql数据一致性

在项目中，redis一般作为缓存使用，从而加快系统的读写效率和吞吐量，但是数据最终一般是存储在mysql中，因此在实际开发中，尤其是在高并发的互联网项目中，经常会遇到这种mysql和redis数据不一致的情况。如在一个电商的扣减库存的场景中，如果redis中的数据和mysql中的数据没有保证一致，那么就很有可能造成超卖的问题，那么平台就可能会因为这个问题造成商家的损失

1，数据不一致原因

数据不一致原因无非就是那几种原因，在分布式场景中，并发带来的问题，网络抖动带来的问题，分布式事务不一致问题等。

1.1，更新缓存出现的问题

如下面这个场景，以扣减库存的场景为例，假设有100个库存，此时多个线程对该商品下单。如在一个4s的时间线内，线程1和线程2先后下单，在不考虑mysql事务的情况下，来查看以下会出现的问题，其流程如下：

首先在第一秒时线程1进行一个扣减库存操作，但是由于网络卡顿的原因，导致在第4秒才更新redis的缓存只为95，并且写入mysql的数据也为95；
在第二秒时线程2也下单10件商品，此时redis缓存还是100，因此操作的还是这个100，那么扣减库存之后的值变成90，然后在第三秒时更新缓存值为90；
由于暂时不考虑事务，因此此时mysql的值为100-10-5为85，而redis中的缓存值由于覆盖的问题导致还是95，此时就出现了mysql和redis值不一致的问题。

在这里插入图片描述

1.2，删除缓存出现的问题

更新缓存指的是在写完mysql数据之后立马就去更新缓存，效率可能会低一些，除了更新缓存还可以删除缓存，就是在写的时候不更新缓存，而是直接删掉缓存，再读数据的时候进行redis缓存数据的写入，如以下流程

首先线程1在第一秒时扣减5个库存，然后将缓存删除，此时redis中的值为95
第二秒一个线程3来读数据，发现缓存没有就读数据库，此时数据库的值为95
在第三秒有一个用户下单，扣减库存操作为10，此时mysql中为85，删除缓存
由于卡顿问题，在第四秒线程3才执行更新缓存操作，但是拿的值不是最新值，导致原本redis值为85的，由于覆盖的问题此时redis的值为95，导致redis和mysql数据不一致的问题

在这里插入图片描述

1.3，理想情况

在理想情况下，我们更希望的是每个命令都可以顺序执行，将各种无法预料的并发问题直接改成串行化操作。当然如果在此基础上进行优化的话，在加锁的同时，考虑加一把互斥锁，从而保证读读共享，其他互斥的操作

在这里插入图片描述

2，数据不一致解决方案

2.1，延迟双删(不推荐)

延迟双删顾名思义，就是延迟一段时间，删除某些线程因为卡顿原因导致更新缓存的值出错，如下图线程3由于卡顿，造成缓存覆盖的问题，从而导致了redis中缓存和mysql中的值出现不一致的问题，但是通过延迟双删的方式，对缓存做两次删除，并且两次删除间设置一定的时间间隔，从而解决部分卡顿问题

在这里插入图片描述

其伪代码如下，首先是第一次删除缓存，然后休眠个300秒，然后再次删除缓存。

#第一次删除缓存
redis.delKey(phone:1001)
#休眠300毫秒
Thread.sleep(300)
#再删除缓存
redis.delKey(phone:1001)

延迟双删的方式也不能完全解决这种数据不一致问题，只能减少这种数据不一致概率的事件发生，因为不能保证某些查询的线程要卡顿多久，比如我设置300毫秒，但是有的线程卡顿一秒，因此也不能够完全解决。

其次所有的写操作都得删除两次，这对redis来说会有一定的性能影响，除了本身的操作之外，还得额外的增加一段延时的时间，对于使用redis的初衷来说就没那么友好，更加的适用于 读多写少 的场景，如商品首页等。

2.2，消息队列

如果为了强一致性，那么可以直接使用消息队列来使用，其本质也很简单，将并行的操作，全部加入到消息队列中串行执行。

消息队列确实可以解决这种数据不一致问题，因为都串行执行，不会有那种并行和并发的问题。但是使用消息队列需要额外的引入中间件，还需要考虑数据的持久化，不丢失，以及顺序消费等问题，如果整个系统是已经有再使用消息中间件的话，如kafka、rocketMq这些，那么是可以考虑使用这种方式的

在这里插入图片描述

2.3，分布式锁

在上一篇中，讲解了redis分布式锁的使用和底层原理，分布式锁的机制和上面的消息队列的机制一样，都是将并行执行的操作方式改成串行的执行方式，直接通过redisson实现的分布式锁即可

RLock lock = redisson.getLock(PHONE_ID);
lock.lock();
lock.unlock();

通过这种分布所锁机制，可以保证数据的串行执行，不出现redis数据脏写问题和覆盖问题

在这里插入图片描述

当然也可以通过redis的 读写锁 进行优化，部分代码如下，直接在读的接口中使用读锁，使用后需要释放锁

//获取一把读写锁
RReadWriteLock readWriteLock = redissoon.getReadWriteLock(lockKey);
//获取读锁
RLock readLock = readWriteLock.readLock();
//加锁
readLock.lock();
//解锁
readLock.unlock();

写的接口中使用写锁即可，使用后也许把锁释放。

//获取一把读写锁
RReadWriteLock readWriteLock = redissoon.getReadWriteLock(lockKey);
//获取写锁
RLock writeLock = readWriteLock.writeLock();
//加锁
writeLock.lock();
//解锁
writeLock.unlock();