redis:四、双写一致性的原理和解决方案(延时双删、分布式锁、异步通知MQ/canal)、面试回答模板

2023-12-16 13:34:08

双写一致性

场景导入

如果现在有个数据要更新,是先删除缓存,还是先操作数据库呢?当多个线程同时进行访问数据的操作,又是什么情况呢?

以先删除缓存,再操作数据库为例

多个线程运行的正常的流程应该如下:
线程1先访问数据,它首先删除缓存,然后更新数据库。之后线程2来查询缓存,未命中后查询数据库,随后写入缓存。
也就是说,线程1负责删除缓存并更新数据库,线程2负责查询数据库并写入缓存。
在这里插入图片描述

但如果线程2在线程1还未更新数据库的时候,就查询数据库了,那么就会出问题。
在这里插入图片描述

以先操作数据库,再删除缓存为例。

正常流程应该如下:
线程2负责更新数据库并删除缓存。线程1负责查询数据库,并写入缓存。
其实也可以说

线程1负责更新数据库并删除缓存。线程2负责查询数据库,并写入缓存。

我把上面的“以先删除缓存,再操作数据库为例”搬过来了,可以对比一下。

也就是说,线程1负责删除缓存并更新数据库,线程2负责查询数据库并写入缓存。

发现就是前半部分顺序颠倒了而已。
在这里插入图片描述
同样的,

但如果线程1在线程2还更新数据库的时候,就查询数据库了,那么就会出问题。

我同样把上面的异常情况搬过来对比。

但如果线程2在线程1还未更新数据库的时候,就查询数据库了,那么就会出问题。

在这里插入图片描述

定义

当修改了数据库的数据也要同时更新缓存的数据,缓存和数据库的数据要保持一致

解决方案

能保障强一致性:延时双删、分布式锁
不能保障强一致性,只能保障最终的一致性:异步通知

延时双删(强一致性)

延时双删就是正常删除缓存、修改数据库后还要延时一会再次删除缓存。
在这里插入图片描述
因为从上面的场景导入,我们发现,无论是先删除缓存还是先修改数据库,都会有数据不一致,即脏数据的风险。

再次把先删除缓存,再修改数据库的异常流程图拿过来,我们发现整个流程走完后,线程1更新数据库,拿到的是正确的值。而线程2拿到的是错误的值,这时只要我们以数据库为主,删除缓存,再写入数据库的值,那么就能拿到正确的值。

在这里插入图片描述
此外,延时一会是因为一般数据库都是主从分离,读写分离的。延时是为了让主库有时间通知到从库,所有数据库的更新操作全部走完。
延时双删极大程度上避免了脏数据的风险,但因为有延时的存在,延时时间不好控制,所以也不能说百分百避免。

分布式锁(强一致性)

互斥锁

直接加互斥锁能保障数据的强一致性,但是性能较低。此时我们就需要优化一下互斥锁。因为存入缓存的数据,一般都是读多写少。为此我们引入两个单独的锁,分别叫共享锁和排他锁。

共享锁/读锁

共享锁,又叫读锁(readLock),加锁之后,其他线程可以共享读操作。

排他锁/独占锁

排他锁,又叫独占锁(writeLock),加锁之后,阻塞其他线程读和写操作。

混合使用的流程和代码

在这里插入图片描述
我们想要拿到共享锁或者排他锁,都需要先拿到读写锁。
通过固定代码可以拿到读写锁。

RReadWriteLock readWriteLock = redissonClient.getReadWriteLock("ITEM_READ_WRITE_LOCK");

随后分别拿到共享锁和排他锁。(注意两个锁需要是同一把读写锁)

RLock readLock = readWriteLock.readLock();
RLock writeLock = readWriteLock.writeLock();

读操作的代码

public void getById(Integer id){
  RReadWriteLock readWriteLock = redissonClient.getReadWriteLock("ITEM_READ_WRITE_LOCK");
  RLock readLock = readWriteLock.readLock();
  try{
    readLock.lock();
    System.out.println("readLock...");
    Item item = (Item) redisTemplate.opsForValue().get("item"+id);
    if(item != null){
      return item;
    }
    item = new Item(id, "华为手机", "华为手机", 5999.00);
    redisTemplate.opsForValue().set("item"+id, item);
    return item;
  }finally{
    readLock.unlock();
  }
}

写操作的代码

public void updateById(Integer id){
  RReadWriteLock readWriteLock = redissonClient.getReadWriteLock("ITEM_READ_WRITE_LOCK");
  RLock writeLock = readWriteLock.writeLock();
  try{
    writeLock.lock();
    System.out.println("writeLock...");
    Item item = new Item(id, "华为手机", "华为手机", 5299.00);
    try{
      Thread.sleep(10000);
    }catch(InterruptedException e){
      e.printStackTrace();
    }
    redisTemplate.delete("item"+id);
  }finally{
    writeLock.unlock();
  }
}

异步通知

异步通知的也有两个主流方案:MQ、Canal
在这里插入图片描述


在这里插入图片描述
canal的方案对于业务代码几乎是零侵入的。

面试回答模板

redis为缓存,mysql的数据如何与redis进行同步呢?

背熟以下回答,大概用时1min。

这个要看业务需求,如果要求数据的强一致性,那么一般使用读写锁来实现。读写锁是一种分布式锁机制,里面包括两种锁,一个叫共享锁,在读的时候添加共享锁,可以保证读读不互斥,读写互斥。一个叫排他锁,在写的时候添加排他锁,可以保证读写都互斥,避免脏数据的风险。
如果不要求数据的强一致性,那么就可以用基于MQ或者canal中间件的异步通知,来实现redis和mysql的双写一致性。

你的项目中用到了redis,那你mysql的数据如何与redis进行同步呢?

——————————————强一致性策略——————————————————

以我最近做的这个项目为例,里面有xxxx(根据自己的简历上写)的功能,需要让数据库与redis高度保持一致,因为要求时效性比较高,我们当时采用的读写锁保证的强一致性。
读写锁是一种分布式锁机制,里面包括两种锁,一个叫共享锁,在读的时候添加共享锁,可以保证读读不互斥,读写互斥。一个叫排他锁,在写的时候添加排他锁,可以保证读写都互斥,避免脏数据的风险。这里面需要注意的是读方法和写方法上需要使用同一把锁才行。

面试官:那这个排他锁是如何保证读写、读读互斥的呢?

候选人:其实排他锁底层使用也是setnx,保证了同时只能有一个线程操作锁住的方法

面试官:你听说过延时双删吗?为什么不用它呢?

候选人:延迟双删,如果是写操作,我们先把缓存中的数据删除,然后更新数据库,最后再延时删除缓存中的数据,其中这个延时多久不太好确定,在延时的过程中可能会出现脏数据,并不能保证强一致性,所以没有采用它。

——————————————非强一致性策略——————————————————

面试官:redis做为缓存,mysql的数据如何与redis进行同步呢?(双写一致性)

候选人:嗯!就说我最近做的这个项目,里面有xxxx(根据自己的简历上写)的功能,数据同步可以有一定的延时(符合大部分业务)

我们当时采用的阿里的canal组件实现数据同步:不需要更改业务代码,部署一个canal服务。canal服务把自己伪装成mysql的一个从节点,当mysql数据更新以后,canal会读取binlog数据,然后在通过canal的客户端获取到数据,更新缓存即可。

文章来源:https://blog.csdn.net/zhiaidaidai/article/details/135030539
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。