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中，因此在实际开发中，尤其是在高并发的互联网项目中，经常会遇到这种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();

不管是原生的Redission锁还是这种读写锁，底层都是通过lua脚本实现，这种方式也更加的适用于 读多写少 的场景。相对于消息队列，可以选这种方式实现

2.4，canal同步

上面几种方式都是需要通过手动的删除缓存或者更新缓存的数据实现数据同步，除了上面几种方式之外，还可以用阿里的canal开源中间件来实现数据的同步，并且通过这种方式，不需要认为的去操作缓存

其原理也很简单，就类似于mysql的主从复制原理，伪装成一个从结点，监听mysql的binlog日志，然后将执行的mysql的操作，通过这个canal中间件同步到redis中。

这样的话，也不需要去考虑redis的更新和删除操作，只需要查即可，查不到再查mysql。

当然如果想直接使用这种canal中间件的话，需要手动的重新部署，也相当于重新引入了一个新的中间件。如果数据量大的话，可以考虑使用这种方式来解决数据不一致问题。