【43-本地锁-分布式锁概念原理-分布式锁解决方案-Redis实现分布式锁-Redisson分布式锁-项目整合Redisson-缓存数据一致性问题-解决缓存一致性的方案-SpringCache缓存】

已于 2022-12-01 23:00:57 修改
阅读量647 收藏 2
点赞数 1
分类专栏： 三高商城系统 文章标签： SpringCache缓存 分布式锁解决方案 Redisson分布式锁 缓存一致性的方案 Redis实现分布式锁
于 2022-12-01 22:57:22 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/Coder_ljw/article/details/128126478
版权

一.知识回顾

【0.三高商城系统的专题专栏都帮你整理好了，请点击这里！】
【1-系统架构演进过程】
【2-微服务系统架构需求】
【3-高性能、高并发、高可用的三高商城系统项目介绍】
【4-Linux云服务器上安装Docker】
【5-Docker安装部署MySQL和Redis服务】
【6-Git安装与配置过程、Gitee码云上创建项目、IDEA关联克隆的项目】
【7-创建商城系统的子模块并将修改后的信息使用Git提交到Gitee上】
【8-数据库表结构的创建&后台管理系统的搭建】
【9-前端项目的搭建部署、Node安装、VSCode安装】
【10-Node的安装以及全局环境变量的相关配置&解决启动报错的问题(1.Error: Cannot find module ‘fs/promises)(2.npm安装node-sass报错)】
【11-导入人人generator项目并自动生成相关的文件&商品子模块的调试&公共模块common子模块的抽离与实现&Lombok插件的安装】
【12-商品子模块整合MyBatisPlus技术&其它模块通过generator的自动生成与补充完善】
【13-项目中微服务组件的学习-SpringCloudAlibaba微服务生态体系的学习&SpringCloudAlibaba的依赖管理&项目中SpringBoot和SpringCloud版本的统一】
【14-微服务的注册中心与配置中心Nacos&Windows操作系统上安装Nacos和Linux操作系统上用Docker中安装Nacos&每个子项目模块使用Nacos进行服务注册与发现】
【15-项目中服务的远程调用之OpenFeign&订单模块与商品模块集成使用OpenFeign的案例】
【16-配置中心之Nacos的基本使用&Nacos服务之命令空间、Nacos服务之配置组、Nacos服务之配置拆分】
【17-微服务网关之Spring Cloud Gateway&Spring Cloud Gateway网关服务搭建】
【18-业务开发-基础业务-商品模块-分类管理-前后端管理系统的启动-为分类管理表增加数据-Json插件的下载-返回具有层级目录、父子关系结构的数据】
【19-业务开发-基础业务-商品模块-分类管理-管理系统新建菜单-后端项目renren注册到Nacos注册中心和配置中心去-项目gateway网关模块的搭建-浏览器的同源策略与解决跨域问题实操案例】
【20-业务开发-基础业务-商品模块-分类管理-前端展示后端具有层级关系的目录数据-商品系统三级分类的逻辑删除前后端代码实现】
【21-业务开发-基础业务-商品模块-分类管理-商品系统三级分类的新增类别前后端代码实现-商品系统三级分类的更新类别前后端代码实现-之前错误的Bug修正】
【22-业务开发-基础业务-商品模块-分类管理-商品系统三级分类拖拽页面的功能-前后端代码的逻辑实现-访问测试-拖拽开关的开启和关系-批量更新拖拽数据-批量删除选定数据】
【23-业务开发-基础业务-品牌管理-品牌管理项目搭建-品牌管理实现的增删改查操作测试-后端数据显示状态使用前端组件开关按钮展示-以及数据处理以及测试】
【24-业务开发-基础业务-品牌管理-图片管理-阿里云OSS服务开通和使用-阿里云OSS服务API使用-SpringCloudAlibaba OSS服务的使用】
【25-业务开发-基础业务-品牌管理-图片管理-图片上传方式的三种实现方式-第三方公共服务模块集成到项目中-服务端生成签名实战】
【26-业务开发-基础业务-品牌管理-图片管理-上传图片功能实现-基于阿里云OSS服务-解决跨域问题-设置跨域规则-修改ACL权限为公共读】
【27-业务开发-基础业务-品牌管理-图片管理-添加修改品牌信息并显示图片-前端数据校验-后端数据JSR303校验实现-统一异常处理-自定义响应编码规则-分组校验-自定义校验注解-项目Bug解决】
【28-业务开发-基础业务-属性管理-SKU和SPU基本概念-SKU和SPU关联关系-属性实体之间的关联关系-批量菜单创建】
【29-业务开发-基础业务-属性管理-属性组业务逻辑开发-页面布局-三级分类组件功能-属性组表单-父子组件传值-属性组数据展示-属性组数据添加-属性组数据修改-前后端项目整合交互测试】
【30-业务开发-基础业务-品牌管理-分类维护-解决分类维护业务开发中的一个Bug-品牌管理-分页插件-分页功能的逻辑实现-品牌管理-检索条件模糊查询品牌管理-增加更新操作中排序字段检验还是存在问题】
【31-业务开发-基础业务-品牌管理-级联类别信息业务功能实现-品牌管理和商品分类管理俩者业务关联出现数据冗余，导致数据不同步的问题-开启事务-项目测试】
【32-业务开发-基础业务-规格参数-保存数据-查询数据-更新操作之数据回显展示-更新操作-前后端项目交互整合与测试-总结收获】
【33-业务开发-基础业务-规格参数-销售属性-多表之间的关联增删改查操作-前后端项目交互整合与测试-Cannot read property ‘publish‘ of undefined】
【34-业务开发-基础业务-属性组和基本属性-属性组和基本属性建立关联-属性组和基本属性解除关联-未关联属性查询-确认新增】
【35-业务开发-基础业务-商品服务-新增商品-会员模块服务-mall-member-会员模块数据维护-规格参数维护-前端项目Bug解决-PubSub依赖缺失】
【36-业务开发-基础业务-商品服务SPU-前后端处理商品数据Json-发布商品前后端业务逻辑-feign服务远程调用-DTO数据传输对象-商品服务的检索-商品管理的检索项目中修改更正完善逻辑操作】
【37-业务开发-基础业务-库存管理- 仓库模块Nacos注册中心的配置-Gateway网关配置-仓库维护的增删改查-商品库存管理-采购流程-采购需求维护-采购需求合并-领取采购单完成采购操作】
【插入------>ElasticSearch专栏相关的知识内容都整理好了，在这里哟！】
【38-商品上架功能结合ElasticSearch全文检索的流程-商品ES关系映射模型&Docker安装ik分词器-实现上架功能复杂的逻辑实现-Postman+Kibana访问测试】
【39-商品整合thymeleaf模板引擎-商城用户端的实现逻辑-部署devtools工具依赖-商品后台-三级分类逻辑分析实现-Docker 安装部署Nginx-Nginx对网关实现反向代理负载均衡】
【40-系统性能压力测试基本概念-相关性能指标HPS&TPS&QPS&RT-安装Jmeter教程-JMeter测试流程-线程组-取样器-监视器-测试商城首页-JMeter Address 占用的问题】
【41-系统性能压力测试优化-JVM知识回顾-jconsole和jvisualvm-jvisualvm安装Visual GC插件-Nginx压力测试- 网关gateway压测-Nginx实现动静分离】
【42-缓存的基本概念-是否使用缓存的场景-本地缓存-分布式缓存-项目中整合Redis-修改三级分类逻辑代码+加入缓存-三级分类加入缓存后压力测试-缓存穿透-缓存雪崩-缓存击穿】

二.本地锁的局限&分布式锁原理

2.1 本地锁的局限

  本地锁在分布式环境下，是没有办法锁住其他节点的操作的，这种情况肯定是有问题的

在这里插入图片描述

2.2 本地锁到分布式锁的演进

针对本地锁的问题，我们需要通过分布式锁来解决，那么是不是意味着本身锁在分布式场景下就不需要了呢？

一个业务网逻辑模块发出很多个请求，而我们使用本地锁是为了让多个请求最后只有一个请求去和其它更少的资源去竞争请求分布式锁
在这里插入图片描述

  显然不是这样的，因为如果分布式环境下的每个节点不控制请求的数量，那么分布式锁的压力会非常大，这时我们需要本地锁来控制每个节点的同步，来降低分布式锁的压力，所以实际开发中我们都是本地锁和分布式锁结合使用的。

2.3 分布式锁的原理

  分布式锁或者本地锁的本质其实是一样的，都是将并行的操作转换为了串行的操作

在这里插入图片描述

三.分布式锁的常用解决方案

3.1 数据库

可以利用MySQL隔离性：唯一索引

use test;
CREATE TABLE `DistributedLock` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键',
  `name` varchar(64) NOT NULL DEFAULT '' COMMENT '锁名',
  `desc` varchar(1024) NOT NULL DEFAULT '备注信息',
  `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '保存数据时间，自动生成',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uidx_name` (`name`) 
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='锁定中的方法';

//数据库中的每一条记录就是一把锁，利用的mysql唯一索引的排他性

lock(name,desc){
    insert into DistributedLock(`name`,`desc`) values (#{name},#{desc});
}

unlock(name){
    delete from DistributedLock where name = #{name}
}

可以利用拍他说来实现 select … where … for update;

乐观锁：乐观的任务数据不会出现数据安全问题，如果出现了就重试一次

select ...,version;
update table set version+1 where version = xxx

3.2 Redis&Redisson

下面会详细介绍Redis和Redisson实战场景，此处不做过多解释。

  1. Redis:setNX: setNX(key,value) :如果key不存在那么就添加key的值，否则添加失败
  2. Redisson：Redisson实现分布式锁框架

3.3 Zookeeper

创建的临时有序节点中每次只有最小的去获取锁，业务逻辑成功后，释放锁，然后下一个节点监听到了做出香瓜的改变。
在这里插入图片描述

四.Redis实现分布式锁

  在Redis中是通过setNX指令来实现锁的抢占，那么利用这个命令实现分布式锁的基础代码为：

    public Map<String, List<Catalog2VO>> getCatelog2JSONDbWithRedisLock() {
        String keys = "catalogJSON";
        // 加锁
        Boolean lock = stringRedisTemplate.opsForValue().setIfAbsent("lock", "1111");
        if(lock){
            // 加锁成功
            Map<String, List<Catalog2VO>> data = getDataForDB(keys);
            // 从数据库中获取数据成功后，我们应该要释放锁
            stringRedisTemplate.delete("lock");
            return data;
        }else{
            // 加锁失败
            // 休眠+重试
            // Thread.sleep(1000);
            return getCatelog2JSONDbWithRedisLock();
        }
    }

  上面的代码其实是存在一些问题的，首先如果getDataForDB(keys)这个方法如果出现的异常，那么我们就不会删除该key也就是不会释放锁，从而造成了死锁，针对这个问题，我们可以通过设置过期时间来解决，具体代码如下：

    public Map<String, List<Catalog2VO>> getCatelog2JSONDbWithRedisLock() {
        String keys = "catalogJSON";
        // 加锁
        Boolean lock = stringRedisTemplate.opsForValue().setIfAbsent("lock", "1111");
        if(lock){
            // 给对应的key设置过期时间
            stringRedisTemplate.expire("lock",20,TimeUnit.SECONDS);
            // 加锁成功
            Map<String, List<Catalog2VO>> data = getDataForDB(keys);
            // 从数据库中获取数据成功后，我们应该要释放锁
            stringRedisTemplate.delete("lock");
            return data;
        }else{
            // 加锁失败
            // 休眠+重试
            // Thread.sleep(1000);
            return getCatelog2JSONDbWithRedisLock();
        }
    }

  上面虽然解决了getDataForDB方法出现异常的问题，但是如果在expire方法执行之前就中断呢？这样也会出现我们介绍的死锁的问题，那这个问题怎么办？这时我们就希望setNx和设置过期时间的操作能够保证原子性。

这时我们就可以在setIfAbsent方法中同时指定过期时间，保证这个原子性的行为

    public Map<String, List<Catalog2VO>> getCatelog2JSONDbWithRedisLock() {
        String keys = "catalogJSON";
        // 加锁 在执行插入操作的同时设置了过期时间
        Boolean lock = stringRedisTemplate.opsForValue().setIfAbsent("lock", "1111",30,TimeUnit.SECONDS);
        if(lock){
            // 给对应的key设置过期时间
            stringRedisTemplate.expire("lock",20,TimeUnit.SECONDS);
            // 加锁成功
            Map<String, List<Catalog2VO>> data = getDataForDB(keys);
            // 从数据库中获取数据成功后，我们应该要释放锁
            stringRedisTemplate.delete("lock");
            return data;
        }else{
            // 加锁失败
            // 休眠+重试
            // Thread.sleep(1000);
            return getCatelog2JSONDbWithRedisLock();
        }
    }

  如果获取锁的业务执行时间比较长，超过了我们设置的过期时间，那么就有可能业务还没执行完，锁就释放了，然后另一个请求进来了，并创建了key，这时原来的业务处理完成后，再去删除key的时候，那么就有可能删除别人的key，这时怎么办?针对这种情况我们可以查询的锁的信息通过UUID来区分，具体的代码如下：

public Map<String, List<Catalog2VO>> getCatelog2JSONDbWithRedisLock() {
        String keys = "catalogJSON";
        // 加锁 在执行插入操作的同时设置了过期时间
        String uuid = UUID.randomUUID().toString();
        Boolean lock = stringRedisTemplate.opsForValue().setIfAbsent("lock", uuid,30,TimeUnit.SECONDS);
        if(lock){
            // 给对应的key设置过期时间
            stringRedisTemplate.expire("lock",20,TimeUnit.SECONDS);
            // 加锁成功
            Map<String, List<Catalog2VO>> data = getDataForDB(keys);
            // 获取当前key对应的值
            String val = stringRedisTemplate.opsForValue().get("lock");
            if(uuid.equals(val)){
                // 说明这把锁是自己的
                // 从数据库中获取数据成功后，我们应该要释放锁
                stringRedisTemplate.delete("lock");
            }
            return data;
        }else{
            // 加锁失败
            // 休眠+重试
            // Thread.sleep(1000);
            return getCatelog2JSONDbWithRedisLock();
        }
    }

  上面查询key的值和删除key其实不是一个原子性操作，这就会出现我查询出来key之后，时间过期了，然后key被删除了，然后其他的请求创建了一个新的key，然后原来的执行删除了这个key，又出现了删除别人key的情况。这时我们需要保证查询和删除是一个原子性行为。

public Map<String, List<Catalog2VO>> getCatelog2JSONDbWithRedisLock() {
        String keys = "catalogJSON";
        // 加锁 在执行插入操作的同时设置了过期时间
        String uuid = UUID.randomUUID().toString();
        Boolean lock = stringRedisTemplate.opsForValue().setIfAbsent("lock", uuid,300,TimeUnit.SECONDS);
        if(lock){
            Map<String, List<Catalog2VO>> data = null;
            try {
                // 加锁成功
                data = getDataForDB(keys);
            }finally {
                String srcipts = "if redis.call('get',KEYS[1]) == ARGV[1]  then return redis.call('del',KEYS[1]) else  return 0 end ";
                // 通过Redis的lua脚本实现 查询和删除操作的原子性
                stringRedisTemplate.execute(new DefaultRedisScript<Integer>(srcipts,Integer.class)
                        ,Arrays.asList("lock"),uuid);
            }
            return data;
        }else{
            // 加锁失败
            // 休眠+重试
            // Thread.sleep(1000);
            return getCatelog2JSONDbWithRedisLock();
        }
    }

五.Redisson分布式锁

5.1 Redisson的整合

添加对应的依赖

        <dependency>
            <groupId>org.redisson</groupId>
            <artifactId>redisson</artifactId>
            <version>3.16.1</version>
        </dependency>

在这里插入图片描述

添加对应的配置类

@Configuration
public class MyRedisConfig {

    @Bean
    public RedissonClient redissonClient(){
        Config config = new Config();
        // 配置连接的信息
        config.useSingleServer().setAddress("redis://IP地址:6379");
        RedissonClient redissonClient = Redisson.create(config);
        return  redissonClient;
    }
}

5.2 可重入锁

5.2.1 可重入锁进行加锁是否设置过期时间重载方法的解析
  1. 如果我们指定了锁的过期时间，那么在源码中会直接帮我们创建一个过期时间是指定值的锁，时间到期后就会直接把该锁给删除
  2. 如果我们没有指定过期时间，那么在执行的时候首先会创建一把锁且过期时间是30s然后会创建异步任务，每个10s执行一次任务来续期
5.2.2 可重入锁进行加锁不设置过期时间
  1. 锁会自动续期，如果业务时间超长，运行期间Redisson会自动给锁重新添加30s，不用担心业务时间，锁自动过去而造成的数据安全问题
  2. 加锁的业务只要执行完成， 那么就不会给当前的锁续期，即使我们不去主动的释放锁，锁在默认30s之后也会自动的删除
    @ResponseBody
    @GetMapping("/hello")
    public String hello(){
        RLock myLock = redissonClient.getLock("myLock");
        // 加锁
        myLock.lock();
        try {
            System.out.println("加锁成功...业务处理....." + Thread.currentThread().getName());
            Thread.sleep(30000);
        }catch (Exception e){

        }finally {
            System.out.println("释放锁成功..." +  Thread.currentThread().getName());
            // 释放锁
            myLock.unlock();
        }
        return "hello";
    }
5.2.3 可重入锁进行加锁设置过期时间
  1. 指定了过期时间后那么自动续期就不会生效了，这时我们就需要注意设置的过期时间一定要满足我们的业务场景
  2. 但是实际开发中我们最好指定过期时间–>性能角度考虑

5.3 读写锁

  1. 根据业务操作我们可以分为读写操作，读操作其实不会影响数据，那么如果还对读操作做串行处理，效率会很低，这时我们可以通过读写锁来解决这个问题。
  2. 读 读 ： 相对于没有加锁
    写 读 ： 需要等待写锁释放
    写 写 ： 阻塞的方式
    读 写 ： 读数据的时候也会添加锁，那么写的行为也会阻塞
  3. 在读写锁中，只有读读的行为是共享锁，相互之间不影响，只要有写的行为存在，那么就是一个互斥锁(排他锁)
	@GetMapping("/writer")
    @ResponseBody
    public String writerValue(){
        RReadWriteLock readWriteLock = redissonClient.getReadWriteLock("rw-lock");
        // 加写锁
        RLock rLock = readWriteLock.writeLock();
        String s = null;
        rLock.lock(); // 加写锁
        try {
            s = UUID.randomUUID().toString();
            stringRedisTemplate.opsForValue().set("msg",s);
            Thread.sleep(30000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        } finally {
            rLock.unlock();
        }
        return s;
    }

    @GetMapping("/reader")
    @ResponseBody
    public String readValue(){
        RReadWriteLock readWriteLock = redissonClient.getReadWriteLock("rw-lock");
        // 加读锁
        RLock rLock = readWriteLock.readLock();
        rLock.lock();
        String s = null;
        try {
            s = stringRedisTemplate.opsForValue().get("msg");
        }finally {
            rLock.unlock();
        }

        return s;
    }

5.4 闭锁

基于Redisson的Redisson分布式闭锁（CountDownLatch）Java对象 RCountDownLatch采用了与 java.util.concurrent.CountDownLatch相似的接口和用法。

@GetMapping("/lockDoor")
    @ResponseBody
    public String lockDoor(){
        RCountDownLatch door = redissonClient.getCountDownLatch("door");
        door.trySetCount(5);
        try {
            door.await(); // 等待数量降低到0
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        return "关门熄灯...";
    }

    @GetMapping("/goHome/{id}")
    @ResponseBody
    public String goHome(@PathVariable Long id){
        RCountDownLatch door = redissonClient.getCountDownLatch("door");
        door.countDown(); // 递减的操作
        return id + "下班走人";
    }

5.5 信号量(Semaphore)

基于Redis的Redisson的分布式信号量（Semaphore）Java对象

RSemaphore采用了与 java.util.concurrent.Semaphore相似的接口和用法。同时还提供了异步（Async）、反射式（Reactive）和RxJava2标准的接口。

@GetMapping("/park")
    @ResponseBody
    public String park(){
        RSemaphore park = redissonClient.getSemaphore("park");
        boolean b = true;
        try {
            // park.acquire(); // 获取信号 阻塞到获取成功
            b = park.tryAcquire();// 返回获取成功还是失败
        } catch (Exception e) {
            e.printStackTrace();
        }
        return "停车是否成功:" + b;
    }

    @GetMapping("/release")
    @ResponseBody
    public String release(){
        RSemaphore park = redissonClient.getSemaphore("park");
        park.release();
        return "释放了一个车位";
    }

六.缓存数据一致性问题

目前一般主流系统使用redis+mysql来保证高并发高性能。那么不可避免的会遇到缓存双写一致性问题—即缓存和数据库数据不一致。

6.1 双写模式

双写模式：就是写完数据库之后再去写缓存，保持缓存一致性；
image.png
存在的问题:
双写模式存在的问题:当一个请求写完数据库后，还没有更新缓存，此时又来了一个请求，直接写了数据库，并且立刻写了缓存，完成后，此时轮到了第一个请求写缓存数据，此时将第二个请求的缓存数据直接修改了。此时存在脏数据的问题，但是当我们设置的key的缓存事件过期后，又会重新拉取最新的数据进行覆盖。

6.2 失效模式

失效模式：简言之就是写完数据库，不用写缓存，而是删缓存，等有请求进来读数据的时候，缓存中没有，就会查数据库，然后主动放到缓存里面。也叫触发主动更新；
image.png
存在的问题一：删除缓存失败，导致Redis和mysql的数据不一致。
存在的问题二：删除缓存成功，但mysql主从时延问题，导致读操作回源时出现数据不一致

6.3 解决缓存一致性的方案

  1. 缓存的所有数据我们都加上过期时间，数据过期之后主动触发更新操作
  2. 使用读写锁来处理，读读的操作是不相互影响的

无论是双写模式还是失效模式，都会导致缓存的不一致问题。即多个实例同时更新会出事。怎么办？

  1. 如果是用户纬度数据（订单数据、用户数据），这种并发几率非常小，不用考虑这个问题，缓存数据加上过期时间，每隔一段时间触发读的主动更新即可
  2. 如果是菜单，商品介绍等基础数据，也可以去使用canal订阅binlog的方式。
  3. 缓存数据+过期时间也足够解决大部分业务对于缓存的要求。
  4. 通过加锁保证并发读写，写写的时候按顺序排好队。读读无所谓。所以适合使用读写锁。（业务不关心脏数据，允许临时脏数据可忽略）

总结：

  • 我们能放入缓存的数据本就不应该是实时性、一致性要求超高的。所以缓存数据的时候加上过期时间，保证每天拿到当前最新数据即可。
  • 我们不应该过度设计，增加系统的复杂性
  • 遇到实时性、一致性要求高的数据，就应该查数据库，即使慢点。

七.SpringCache

SpringCache官方网站参考手册

7.1 整合SpringCache

pom文件中导入依赖在这里插入图片描述

配置文件中设置相关的信息
在这里插入图片描述

主启动类中加入放开缓存的注解
在这里插入图片描述

7.2 缓存注解应用

SpringCache的原理
CacheAutoConfiguration–》根据指定的spring.cache.type=reids会导入 RedisCacheAutoConfiguration

下面就是SpringCache缓存的解决方案，只需要通过这几个注解就可以完成缓存的操作，从而和具体的缓存实现解耦的操作。

触发缓存的保存操作
@Cacheable: Triggers cache population.
更新操作触发数据从缓存中删除的操作
@CacheEvict: Triggers cache eviction.
在不影响方法执行的操作下更新缓存
@CachePut: Updates the cache without interfering with the method execution.
上下注解的组合操作
@Caching: Regroups multiple cache operations to be applied on a method.
在类级别共享缓存的相关数据
@CacheConfig: Shares some common cache-related settings at class-level.
7.2.1 @Cacheable缓存注解使用注意事项

@Cacheable({“catagory”,“product”})

在注解中我们可以指定对应的缓存的名称，起到一个分区的作用，一般按照业务来区分@Cacheable({“catagory”,“product”}) 代表当前的方法的返回结果是需要缓存的，调用该方法的时候，如果缓存中有数据，那么该方法就不会执行，如果缓存中没有数据，那么就执行该方法并且把查询的结果缓存起来。

7.2.2 缓存处理
  1. 存储在Redis中的缓存数据的Key是默认生成的：缓存名称::SimpleKey[]
  2. 默认缓存的数据的过期时间是-1永久
  3. 缓存的数据，默认使用的是jdk的序列化机制
7.2.3 缓存改进：

  1. 生成的缓存数据我们需要指定自定义的key： key属性来指定，可以直接字符串定义也可以通过SPEL表达式处理：#root.method.name
    在这里插入图片描述

  2. 指定缓存数据的存活时间: spring.cache.redis.time-to-live 指定过期时间

spring:
  cache:
    redis:
      time-to-live: 60000 # 指定缓存key的过期时间
  1. 把缓存的数据保存为JSON数据,通过我们自定义配置对象来自定义序列化对象的方式
    在这里插入图片描述
7.2.4 @CacheEvict缓存注解使用注意事项

@CacheEvict：在更新数据的时候同步删除缓存中的数据
@CacheEvict(value = “catagory”,key=“‘getLeve1Category’”)，更新数据时候删除catagory分区下key是getLeve1Category的数据
@CacheEvict(value = “catagory”,allEntries = true) 表示删除catagory分区下的所有的缓存数据–方式一
@Caching(evict = {
@CacheEvict(value = “catagory”,key=“‘getLeve1Category’”)
,@CacheEvict(value = “catagory”,key=“‘getCatelog2JSON’”)
})，如果想要有选择的清除catagory分区下的缓存数据应该使用上面这种方法—方式二

7.3 SpringCache缓存总结

1).读模式

  • 缓存穿透：查询一个null的数据。可以解决 cache-null-values=true
  • 缓存击穿:大量并发进来同时查询一个正好过期的数据。解决方案：分布式锁 sync=true 本地锁
  • 缓存雪崩：大量的key同一个时间点失效。解决方案：添加过期时间 time-to-live=60000 指定过期时间

2).写模式

  • 读写锁
  • 引入canal，监控binlog日志文件来同步更新数据
  • 读多写多，直接去数据库中读取数据即可

总结：

  • 常规数据(读多写少)：而且对及时性和数据的一致性要求不高的情况，我们完全可以使用SpringCache
  • 特殊情况：特殊情况特殊处理。

好了，关于【43-本地锁-分布式锁概念原理-分布式锁解决方案-Redis实现分布式锁-Redisson分布式锁-项目整合Redisson-缓存数据一致性问题-解决缓存一致性的方案-SpringCache缓存】就先学习到这里，更多的内容持续学习中，敬请期待。

硕风和炜
关注
专栏目录
本地锁和分布式锁的区别
IT界的一只菜鸟
08-04 1349
本地锁和分布式锁的区别1. 本地锁和分布式锁的区别。1.1. 本地锁的意义1.2. 分布式锁的意义2. 本地锁2.1. 常用的本地锁有什么？2.2. 本地锁锁的是什么？2.3. lock锁的原理？2.4. volatile是什么意思？干什么用的？2.41 volatile定义2.42 volatile的可见性2.43 volatile的不保证原子性2.44 如何让volatile保证原子性2.45 volatile禁止指令重排2.5. synchronized原理3. 锁的类型：3.1.
spring-data-redis实现分布式锁
weixin_37777080的博客
12-12 2943
Redis由于数据存储在内存（随机访问内存要比硬盘快100万倍），下面是Google 工程师Jeff Dean在分布式系统PPT中给出的各种访问速度参考值： 访问方式 耗时 L1 cache reference 读取CPU的一级缓存 ～0.5 ns L2 cache reference 读取CPU的二级缓存 ～7ns Mutex lock/unlock 互斥锁\解锁 ～10...
本地锁和分布式锁
w18234850529的博客
04-02 1510
1.本地锁的局限性 常见的本地锁有synchronized和lock锁，这些都是本地锁 2.本地锁带来的问题 1.1 单体应用，如果本地不加同步锁的时候，在高并发的情况下，会发生线程安全问题。 1.2 单体应用，如果加上本地锁的时候，在高并发情况下，可以解决安全问题，但是效率会变低。 但是，在集群的情况下，会怎么样呢？ 问题： 在分布式部署的时候，无法保证只有只有一个进程在当前的程序内执行 解决: 需要一把公共锁(分布式锁) 流程: 此处使用redis ...
分布式锁和本地锁
qq_60638763的博客
05-27 504
分布式锁 大锁 锁所有服务 本地锁 小锁 锁每个服务 分布式通过整合redisson来添加 （locke） 写锁是互斥锁，有一个锁，就必须等释放完才能进行下一个锁 读锁是共享锁 读 +读 相当于无锁 读+写 等读锁释放完，再进行写锁 写+写 相当于阻塞方式 写+读 等写锁释放完，再进行读锁 本地锁可以通过synchronized来解决当然用整合的springCache更好 五个注解解决相关锁的问题 因为这个源码添加...
【java的本地锁到分布式锁介绍】
weixin_47068446的博客
04-07 919
在理解锁实现原理之前先了解一下Java的对象头和Monitor，在JVM中，对象是分成三部分存在的：对象头、实例数据、对其填充。实例数据和对其填充与synchronized无关，这里简单说一下（我也是阅读《深入理解Java虚拟机》学到的，读者可仔细阅读该书相关章节学习）。实例数据存放类的属性数据信息，包括父类的属性信息，如果是数组的实例部分还包括数组的长度，这部分内存按4字节对齐；对其填充不是必须部分，由于虚拟机要求对象起始地址必须是8字节的整数倍，对齐填充仅仅是为了使字节对齐。
受益匪浅！图解Janusgraph系列-并发安全：锁机制（本地锁+分布式锁）超全分析
最新发布
m0_62261166的博客
04-16 1188
JanusGraph的锁机制主要是通过本地锁+分布式锁来实现分布式系统下的数据一致性；分布式锁的控制维度为：property、vertex、edge、index都可以；JanusGraph支持在数据导入时通过前面一致性行为部分所说的LOCKLOCK：数据导入时开启分布式锁保证分布式一致性DEFAULT、FORK：数据导入时关闭分布式锁还有兄弟不知道网络安全面试可以提前刷题吗？费时一周整理的160+网络安全面试题，金九银十，做网络安全面试里的显眼包！
Redis实现分布式锁(附源码+讲义)
07-01
分布式锁有很多种解决方案，今天我们要讲的是怎么使用缓存数据库Redis来实现分布式锁。 课程目标:  理解redis分布式锁的应用场景  掌握redis分布式锁的实现原理  掌握redis分布式锁在微服务项目中的应用  掌握...
springboot-redis分布式锁
08-03
这个项目整合了SpringBoot、Redis分布式锁、Thymeleaf模板引擎、RabbitMQ消息队列以及CAS-Shiro认证授权，提供了秒杀场景的解决方案。通过学习这些技术，我们可以构建出具有高并发处理能力、良好扩展性的分布式系统...
golang实现Redis分布式自旋锁+本地自旋锁
01-20
在Golang中，实现分布式自旋锁和本地自旋锁是一种常见的并发控制策略，用于解决多线程或分布式系统中的资源竞争问题。自旋锁的基本思想是，当一个线程试图获取锁时，如果锁已被其他线程持有，它会不断地检查锁的状态...
redis和redisson实现分布式锁
05-26
首先，Redis分布式锁的实现主要依赖于两个命令：`SETNX`（Set if Not eXists）和`EXPIRE`。`SETNX`命令用于原子性地设置一个键值，如果键不存在，则设置成功，否则返回失败。`EXPIRE`命令则用于为键设置过期时间，以...
redis 本地锁和分布式锁
qq_51682771的博客
10-20 452
作用：当缓存不存在key时，只让一个线程去数据库拿到数据，并将数据放在缓存中，之后的线程只需要访问数据库即可。问题：检查和释放是分开的，从检查到释放这一段时间里，A锁过期，B加锁,导致A检查的时候是A锁，但释放的时候是B锁。注意点： 将数据缓存需要在释放锁之前，如果在释放锁之后才缓存，在释放锁到缓存成功这段时间内还有线程会访问数据库。解决：给每一个锁设置一个uuid，在释放锁的时候先进行检查，只有是自己的锁，才可以释放。问题：A 在执行业务的时候超时了，等到释放锁的时候释放的是B刚加的锁。
本地锁和分布式锁的理解
haohaoxuexiyai的博客
05-01 448
https://www.cnblogs.com/balloon72/p/13177929.html
第三章 本地锁和分布式锁的区别
无奈朝来寒雨晚来风 的博客
03-14 1043
这里还会出现一个问题，当我们的程序在删除锁之前抛出异常退出或者机器直接寄了，没有执行删锁的代码，就会造成死锁问题，所以就需要在占坑的时候设置过期时间，时间到了不管你拉没拉完直接提出厕所，但是一定要注意添加锁和设置过期时间一定要保持原子性，也就是在设置锁的时候就放上过期时间，不然如果我们拿到锁，在设置过期时间之前断电了，也会造成死锁问题。当我们查询数据之后直接释放了同步锁，这时还没有将数据存入缓存，第二个请求就拿到锁执行业务了，它看到缓存中没有数据就再次查询了数据库。
SpringBoot分布锁--本地锁、Redis分布式锁
寒梅弄雪的博客
09-01 579
目录 1.什么是幂等 2.产生原因 3.解决方法 3.1前端js提交禁止，按钮可以用一些js组件 3.2使用Post/Redirect/Get模式 3.3本地锁（重点） 3.4Redis分布式锁 3.5请求事栗 1.什么是幂等 select查询天然幂等 delete删除也是幂等,删除同一个多次效果一样 update直接更新某个值的,幂等 ...
并发编程之本地锁，分布式锁
weixin_45476233的博客
11-25 1901
前言 在某些场景中， 本地锁 在单进程情况下，多个线程访问同一资源，可以本地锁实现。 ① .synchronized关键字 ② . lock接口 分布式锁 在多进程情况下，也就是集群环境下，对同一资源的并发请求，用普通的同步锁会失效，因为不同进程里面，就没有什么内存共享之类的说法，要采用分布式锁实现。 ...
java自学看什么书比较好，面试题附答案
m0_57700563的博客
06-29 210
蚂蚁金服一面：分布式架构 50分钟 个人介绍加项目介绍20分钟 微服务架构是什么，它的优缺点？ ACID CAP BASE理论 分布式一致性协议，二段、三段、TCC，优缺点 RPC过程 服务注册中心宕机了怎么办？ 微服务还有其他什么组件 分布式架构与微服务的关系 你有什么问题要问我的。 蚂蚁金服二面：1个小时 上来不用自我介绍，项目介绍，直接开始 算法来两道 各种排序算法、未排序常规数据查找第K大的数，时间复杂度。 二叉树的深度 操作系统来两道 虚拟内存分页了解不？ 进程和线程区别？ 数据库来
万字详解本地锁到分布式锁的演进、Redis实现以及扩展 Redlock 红锁
2301_76607156的博客
04-13 310
本地锁失效是因为无法锁住各个应用的读写请求，失效的根本原因就是其他的服务无法感知到是否已经有请求上锁了，即无法共享锁信息。分布式锁，其实也就是将加锁的这一个操作，单独的抽取出来了，让每个服务都能感知到。之前就说了，软件架构设计中，"没有什么是加一层解决不了的，如果加一层不行就再加一层这里其实也是一样，只不过碰巧这一层可以在Redis中实现罢了，看起来倒是没有多加一层，但如果是用Zookeeper或者其他方式来实现，你会发现架构中会多一层滴。其实理解思想实现的方式有很多种的，Redis 实现分布式锁。
高并发情况下加锁-本地锁、分布式锁实现
程序员劝退师的博客
07-15 1940
前言 在高并发情况下，要保证服务端的性能，那么会采用缓存来提高服务端的性能，如百万请求访问一个查询的接口，这个接口做了缓存，但是不能保存并发同时到达接口时缓存中也没有数据，恰巧这百万的并发又进入到数据库，那么这时数据库压力过大，导致数据库崩溃，导致服务的不可用，乃至整个系统的崩溃，那么这是由于并发同时绕过了缓存判断直接进入到数据库导致的，这时就可以针对这个并发问题进行加锁 本地锁 单体项目时可以这么做 public R getData { /** *
day103-缓存-缓存使用-本地锁在分布式下的问题
JavaCoder_juejue的博客
02-06 262
1.模拟分布式环境 我们一般的项目都是分布式应用而不是单机的 拷贝配置 拷贝三次设置不同端口号然后启动 2.压测及问题分析 这里要访问gulimall.com为了经过nginx监听然后负载均衡 结果分析 查看到几个应用打印的结果，可以看到有两台机器查询了数据库，为啥呢， 这是因为我们加的锁是加在this对象的，他虽然是单例的，但只是在单机应用中，若是个应用，对象是不一样的 所以出现查询多次数据库的情况,所以我们需要使用分布式锁，来保证加的同一把锁 ...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

硕风和炜

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值