Redis实际应用2

最新推荐文章于 2024-05-29 14:29:08 发布
最新推荐文章于 2024-05-29 14:29:08 发布
阅读量369 收藏
点赞数
分类专栏： sql 文章标签： redis java 数据库
原文链接：https://www.bilibili.com/video/BV1cr4y1671t
版权

目录

全局唯一ID

下订单 这种情况，如果采用数据库的自增，则会规律明显，所以采用手动的情况下生产id
在这里插入图片描述
这是id的生产策略，注意这个32位，后面的代码需要移动32位
在这里插入图片描述

代码：

public class RedisIDWork {
    //当前的时间
    private static final long BEGIN_TIME=1652453880L;

    @Autowired
    private StringRedisTemplate stringRedisTemplate;

    //递增全局id
    public long nextID(String key){
        //生产时间戳
        //产生一个调用时候的时间戳然后减去begin即可完成
        LocalDateTime now = LocalDateTime.now();
        long end = now.toEpochSecond(ZoneOffset.UTC);
        long time=end-BEGIN_TIME;

        //生产序列号
        //获取当天日期
        String format = now.format(DateTimeFormatter.ofPattern("yyyy:MM:dd"));
        //自增长
        Long increment = stringRedisTemplate.opsForValue().increment("icr:" + key + ":" + format);

        //拼接并返回
        return  time<<32 |increment;
    }
}

秒杀下单

背景：

主要是数据库的背景：
是由两张表构成 普通卷 和秒杀卷 秒杀卷有外键链接普通卷
普通卷：
在这里插入图片描述

秒杀卷：
在这里插入图片描述

效果：

在这里插入图片描述

流程：

在这里插入图片描述

代码：

@Transactional
    @Override
    public Result seckillVoucherByvoucherId(Long voucherId) {
        //1:首先查询是否有优惠卷
        SeckillVoucher seckillVoucher = seckillVoucherService.getById(voucherId);
        if (seckillVoucher==null){
            //1.1： 没有返回错误
            return  Result.fail("没有该优惠卷");
        }
        //1.2：有
        //2查询是否开始 或者结束
        LocalDateTime beginTime = seckillVoucher.getBeginTime();
        LocalDateTime endTime = seckillVoucher.getEndTime();
        //判断是否开始
        if (beginTime.isAfter(LocalDateTime.now())){
            //2.1 还没有开始
            return Result.fail("活动暂未开始");
        }
        if (endTime.isBefore(LocalDateTime.now())){
            //2.2过期 返回错误
            return Result.fail("活动已经结束");
        }
        //2.3 有效期之内
        //3 进行库存的查询
        Integer stock = seckillVoucher.getStock();
        if (stock<=0){
            //3.1没有库存 返回信息
            return Result.fail("抱歉该商品已经被抢完了");
        }
        //3.2 还有库存
        //4： 库存减一

        boolean update = seckillVoucherService.update()
                .setSql("stock=stock-1")
                .eq("voucher_id", voucherId).update();
        if (!update){
            return Result.fail("库存不足 插入时失败");
        }
        //5：创建订单
        VoucherOrder voucherOrder=new VoucherOrder();
        //给订单id赋值
        voucherOrder.setId(redisIDWork.nextID("skillVouCher"));
        //优惠卷的id 赋值
        voucherOrder.setVoucherId(voucherId);
        //用户的id  利用拦截器获取到
        voucherOrder.setUserId(UserHolder.getUser().getId());
        //保存到数据库
        save(voucherOrder);
        //返回订单 的id
        return Result.ok(voucherOrder.getId());
    }

效果图：

订单表达到效果 有订单的增加：
在这里插入图片描述
秒杀卷表达到效果 有库存的减少：
在这里插入图片描述

秒杀下的超卖问题

测试

采用jemter进行测试：
在这里插入图片描述

测试结果：

在这里插入图片描述
在这里插入图片描述
不出所料 出现了超卖的问题

原因

原因很简单 ，高并发的访问下，有没有设置锁，当然会造成这种情况的产生。

解决方案：

加锁：
在这里插入图片描述
由于并发不一定经常发生，所以建议采用乐观锁

乐观锁 版本号

在这里插入图片描述
在这里插入图片描述
由于 我们的库存和version 都在改变的 所以完全可以用库存当version
于是有了下面这个方法

乐观锁 CAS法

CAS： compare and set
在这里插入图片描述
在这里插入图片描述

CAS 方法：

代码

只需要在原来的基础上 在插入时进行这样的判断即可：在这里插入图片描述

结果

两白个线程 只卖出26件在这里插入图片描述

原因：

加入 有1个线程修改了 但在他修改的时候 已经有99个线程进来
那么用了这个方法 则会导致 100线程里面 只有一个 能够成功下单。

CAS2.0：

代码：

只需要库存 大于0即可
在这里插入图片描述

结果：

刚好抢完 也刚好100条数据
在这里插入图片描述
在这里插入图片描述

超卖问题的总结

在这里插入图片描述

一人一单

流程修改：

其实很简单，就是订单里面 判断 userid和优惠卷id 是否 已经存在一模一样的，有则证明已经下过单了，没有则没下过
在这里插入图片描述

代码：

只需要添加这一步的判断即可
在这里插入图片描述

结果：

在这里插入图片描述

原因

原因依旧是 高并发下的不安全问题，我们的这个设置时候 依旧可能有线程进来了。

解决方案！！！：

只能是悲观锁了

由于乐观锁需要加版本 适用于修改的，我们的这个业务是插入的业务，初始为空的，哪里来的什么版本

思路
第一步方法拆分

我们的方法 需要加锁的拆除来即可
以一人一单以上的方法都是在进行查询操作，
所以下面需要加事务 加锁 上面的方法则可以把事务取消
在这里插入图片描述
在这里插入图片描述

第二步加锁

思考：

1.0

**1.0：**首先最快想到的是 加在方法上，如下图。但是由于我们的锁一旦加了，如果锁的对象一样 则会进行锁住一个一个执行。加在方法上面锁的的对象是this，每一次不管怎么样都要锁住 效率过于低下，在本场景有更优解。
在这里插入图片描述

2.0

2.0： 我们要预防的是同一个ID的用户，不进行多抢即可。那我们只需要锁住id即可，如下图

在这里插入图片描述
但是这样相当于没锁 为什么？
因为userid 是Long类型的，每一个线程来虽然值一样但是地址是不一样的，
我们的锁看的是地址不是值。
测试结果：
在这里插入图片描述

3.0

3.0 基于上述，我们只需要 保证userid 值对应的对象唯一即可
所以用常量池，第一时间应该想到string，所以转换成string就行了嘛？
看源码：
在这里插入图片描述
依旧会new
正解是采用string的intern 就是 按照值去常量池找 有则返回 常量池里面的，没有则放进去。
在这里插入图片描述

在这里插入图片描述
上锁：
在这里插入图片描述

结果：
在这里插入图片描述
在这里插入图片描述

一人一单的多机问题

准备：

复制服务，开一个8082端口
ctrl+D
在这里插入图片描述
修改Nginx ：
以便于达到负载均衡的效果：
在这里插入图片描述
重启Nginx即可：

测试

代码不变，还是用jemeter 进行测试：
会出现两个订单
在这里插入图片描述

原因

因为是两个服务，常量池都变了，所以会出现锁住了但没完全锁住的情况
在这里插入图片描述

解决方法：

采用分布式锁

分布式锁

原理：

原理的单机锁，是在一个JVM里面进行锁的监视，分布式就是将监视器变成公用的
在这里插入图片描述

分布式锁的几种实现：

在这里插入图片描述

基于Redis的实现1.0：

在这里插入图片描述

代码：

接口类 ILock

public interface ILock {

  /**
   * @description:尝试获取锁
   * @author:Code-zyc
   * @date: 2022/5/15 9:59
   * @param timeout :给锁设置的超时时间
   * @return boolean : 获取成功返回true
   */
    boolean tryLock(Long timeout);

    /**
     * @description: 释放锁
     * @author:Code-zyc
     * @date: 2022/5/15 10:00
     */

    void unlock();
}

实现类 SimpleRedisLock

public class SimpleRedisLock implements ILock{

    private  static final String LOCK_PROFIX="lock:";

    private String key;
    private StringRedisTemplate stringRedisTemplate;

    @Override
    public boolean tryLock(Long timeout) {
        //获取线程名字，作为值存放
        String name = Thread.currentThread().getName();
        // 采用senet 进行存放数据
        Boolean flag = stringRedisTemplate.opsForValue()
                .setIfAbsent(LOCK_PROFIX + key, name, timeout, TimeUnit.SECONDS);

        return Boolean.TRUE.equals(flag);
    }

    @Override
    public void unlock() {
        stringRedisTemplate.delete(LOCK_PROFIX+key);
    }

    public SimpleRedisLock() {
    }

    public SimpleRedisLock(String key, StringRedisTemplate stringRedisTemplate) {
        this.key = key;
        this.stringRedisTemplate = stringRedisTemplate;
    }
}

逻辑处理类
在原来的基础上，把synchronized锁缓存redis锁

@Autowired
    StringRedisTemplate redisTemplate;
    @Transactional
    public  Result createVoucherOvder(Long voucherId){
        //一人一单子
        Long userid = UserHolder.getUser().getId();

        SimpleRedisLock lock=new SimpleRedisLock("order"+userid,redisTemplate);

        if (!lock.tryLock(1200L)){
            //获取失败 直接返回错误或者重写尝试
            return  Result.fail("不能重复下单");
        }
        //下面部分用try包裹起来 最后进行 锁的释放

        try {
            //判断是否下单了
            Integer count = query().eq("user_id", userid)
                    .eq("voucher_id", voucherId)
                    .count();
            if (count>0){
                return  Result.fail("已经购买过了！");
            }

            //4： 库存减一
            boolean update = seckillVoucherService.update()
                    .setSql("stock=stock-1")
                    .eq("voucher_id", voucherId)
                    .gt("stock", 0) //大于0即可
                    .update();
            if (!update){
                return Result.fail("库存不足 插入时失败");
            }
            //5：创建订单
            VoucherOrder voucherOrder=new VoucherOrder();
            //给订单id赋值
            voucherOrder.setId(redisIDWork.nextID("skillVouCher"));
            //优惠卷的id 赋值
            voucherOrder.setVoucherId(voucherId);
            //用户的id  利用拦截器获取到
            voucherOrder.setUserId(userid);
            //保存到数据库
            save(voucherOrder);
            //返回订单 的id
            return Result.ok(voucherOrder.getId());
        } finally {
            lock.unlock();
        }

    }
结果：

非常成功，在分布式的情况下，没有出现 重复购买的情况。
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

Redis实现2.0

1.0的毛病

1.0可能也会产生问题：
在这里插入图片描述
上面这张图片主要就是表达，由于业务阻塞存在，线程1的到期了还没执行完过期了，线程2 来上锁成功了 但是线程1又执行完 来释放锁了出现了恶性循环，导致都能执行了

解决方案

就是 释放锁之前 看看是不是自己的锁，是在进行释放
由于是分布式的，所以不能依靠线程id进行判断，因为每一个JVM是各自维护id的。可以采用UUID+线程ID实现全局唯一性。

流程：

在这里插入图片描述

代码

只需要修改 unlock即可

public class SimpleRedisLock implements ILock{

    private  static final String LOCK_PROFIX="lock:";
    private  static final String VALUE_PROFIX= UUID.randomUUID().toString();

    private String key;
    private StringRedisTemplate stringRedisTemplate;

    @Override
    public boolean tryLock(Long timeout) {
        //创建对应的全局的id
        String value = VALUE_PROFIX+ Thread.currentThread().getId();
        // 采用senet 进行存放数据
        Boolean flag = stringRedisTemplate.opsForValue()
                .setIfAbsent(LOCK_PROFIX + key, value, timeout, TimeUnit.SECONDS);

        return Boolean.TRUE.equals(flag);
    }

    @Override
    public void unlock() {
        //首先获取到 正确的value值
        String value = VALUE_PROFIX+ Thread.currentThread().getId();
        //从缓存中获取到
        String redisvalue = stringRedisTemplate.opsForValue().get(LOCK_PROFIX + key);
        if (value.equals(redisvalue)) {
            //相同表示同一个锁 可以进行释放
            stringRedisTemplate.delete(LOCK_PROFIX+key);
        }
    }

    public SimpleRedisLock() {
    }

    public SimpleRedisLock(String key, StringRedisTemplate stringRedisTemplate) {
        this.key = key;
        this.stringRedisTemplate = stringRedisTemplate;
    }
}
结果

结果成功的略。

Redis实现3.0

2.0的毛病：

依旧是阻塞导致的问题，我们虽然进行判断但是在进行判断的时候，有可能出现判断了 但是要去释放锁的时候阻塞了，这时候别人乘虚而入，导致问题的发生：
在这里插入图片描述

解决方案Lua：

实现检测了上锁的原子性，采用Lua脚本进行实现

代码

Lua脚本代码：
在这里插入图片描述
逻辑代码：
在这里插入图片描述
在这里插入图片描述

Redis锁总结：

在这里插入图片描述

Redission

功能介绍：官网地址
Git地址

前期准备：

导入依赖：

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

写配置类： 或是写在yaml里面

@Component
public class RedissonConfig {
    @Bean
    public RedissonClient redissonClient(){
        Config config=new Config();
        //设值链接地址和密码
        config.useSingleServer().setAddress("redis://192.168.254.138:6379").setPassword("1234");
        return Redisson.create(config);
    }

}

代码

这个相比于前面的版本 只需要修改这几个部分即可：
在这里插入图片描述
tryLock 的构造函数：
在这里插入图片描述
**如果是无参的话：**就是非阻塞的不回去重新获取
在这里插入图片描述
有参的
在这里插入图片描述

自定义的缺陷：

在这里插入图片描述

1：不可重入

就是 同一个锁一个方法调用另一个的时候需要进行获取，但是方法1已经拿到锁了还没释放，所以产生了死锁的情况。
在这里插入图片描述
解决方案 采用记录的方式 先通过唯一标识看看是不是你在调用，是的话获取次数+1 直到为0 才释放锁。
在这里插入图片描述
由于这一些列都必须是 原子性的 所以采用Lua进行编写
获取锁的Lua脚本：
在这里插入图片描述
释放锁的Lua脚本：
在这里插入图片描述
redisson底层也是采用的Lua脚本进行的编辑：
在这里插入图片描述

2，3：

在这里插入图片描述

4：主从一致

进行传输的时候，突然主机挂掉，还未与从机之间进行数据的交流。
在这里插入图片描述
解决方案：
多个主机节点，每一次要设置锁都向这几个进行设置，只有获取到的数量等于了主机的数量，才能算是获取到了锁。
在这里插入图片描述
采用的是redisson自带的： Multilock

补充

关于缓存的过期时间 默认是 30s
在这里插入图片描述
你也可以自己设置：
在这里插入图片描述

Redisson 分布式锁原理

在这里插入图片描述

三种锁的选取总结：

在这里插入图片描述

Code-zyc
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
Redis项目应用场景与实例汇总
我的博客
01-25 6579
文章目录一、背景1.1 开发环境1.2 项目配置二、字符串的应用场景：封锁一个IP地址三、Hash的应用场景：存储用户信息四、List的应用场景：队列实现五、Set的应用场景：自动去重 一、背景 本篇文章是将以前Redis实战的系列文章进行汇总，针对Redis中常用的一些数据结构，进行实战模拟。 strings hashes lists sets sorted sets 封锁一个IP地址 存储用户信息 模拟消息队列 自动排重 以某一个条件为权重，进行排序 1.1 开发环境 JD
Redis数据库的应用场景介绍
09-10
主要介绍了Redis数据库的应用场景介绍,本文讲解了MySql+Memcached架构的问题、Redis常用数据类型、Redis数据类型应用和实现方式、Redis实际应用场景等内容,需要的朋友可以参考下
Redis要点和难点实际应用方向和具体案例代码&代码解析
05-05
Redis要点和难点实际应用方向和具体案例代码&代码解析
基于Redis自增实现全局ID生成器（详解）
向上的咸鱼blueblue的博客
03-08 1637
本文介绍基于Redis自增实现全局ID生成器的思路，同时给出了实现代码
redislock:Redis中的Simple Lock实现。此项目使用jedis的jedis的Java客户端
05-12
重新锁定 Redis中的Simple Lock实现。此项目使用jedis的jedis的Java客户端 例子 简单用例 public static void lockJedisWith(Jedis jedis) { String lockKey = "myKeyToLock"; try (JedisLock jedisLock = LockManager.lock(jedis, lockKey)) { System.out.println("Acquired lock "); } catch (LockException e) { System.out.println("could not acquire lock! Try again later"); } } 锁定到期
一组Redis实际应用中的异常场景及其根因分析和解决方案.docx
10-26
一组Redis实际应用中的异常场景及其根因分析和解决方案.docx
Redis实战案例及问题分析之单机优惠券秒杀
PnJgHT的博客
06-28 352
当用户抢购时，就会生成订单并保存到tb_voucher_order这张表中，而订单表如果使用数据库自增ID就存在如下问题：全局ID生成器，是一种在分布式系统下用来生成全局唯一ID的工具，已满要满足以下特性：为了增加ID的安全性，我们不可以直接使用Redis自增数值，而是拼接一些其他信息 实现优惠券秒杀的下单功能 下单需要判断两点： 优惠券秒杀超卖问题 为什么会出现超卖问题？高并发的情况下，会出现访问量过大，同时拿到了库存大于1的数据，多个线程交叉执行，就会出现超卖问题。超卖问题是典型的多线程
Redis应用场景
weixin_46661912的博客
11-30 6933
redis应用场景总结redis平时我们用到的地方蛮多的，下面就了解的应用场景做个总结 1、热点数据的缓存 由于redis访问速度块、支持的数据类型比较丰富，所以redis很适合用来存储热点数据，另外结合Redis Expire 命令我们可以设置过期时间然后再进行缓存更新操作，这个功能最为常见，我们几乎所有的项目都有所运用。 2、限时业务的运用 redis中可以使用expire命令设置一个键的生存时间，到时间后redis会删除它。利用这一特性可以运用在限时的优惠活动信息、手机验证码等业务场景。 3、计数器相
Redis缓存应用场景解析
怎奈你何的博客
10-25 1519
redis
Redis应用须知
peanut的博客
07-12 359
需要注意的是将数据存入到redis中是需要一定时间的，如果数据得一致性要求很高的话就不要存入到redis中 删除数据不存在这个问题，因为删除数据的话可以先删除缓存中的数据然后再删除市级数据库中的数据，但是插入，修改，这些操作都是要先修改原始数据库中的数据然后在更新缓存的 存中没有数据，那么就直接从关系型数据库中查询...
Redis+MVC实际项目应用（带注释）
06-17
Mvc+Redis 实际项目应用 包含帮助类，注释。
Redis的分布式锁
花&败
01-04 271
Redis 提供了 Lua 脚本功能，在一个脚本中编写多条 Redis 命令，确保多条命令执行时的原子性。Lua 是一种编程语言，它的基本语法大家可以参考网站：https://www.runoob.com/lua/lua-tutorial.html，这里重点介绍 Redis 提供的调用函数，我们可以使用 lua 去操作 redis，又能保证他的原子性，这样就可以实现拿锁比锁删锁是一个原子性动作了，作为 Java 程序员这一块并不作一个简单要求，并不需要大家过于精通，只需要知道他有什么作用即可。
Redis实现全局唯一id
weixin_51472505的博客
08-17 1430
Redis实现全局唯一id
Redis解决商城问题的各种策略
sichenss的博客
04-16 1740
这篇文章是我在学习黑马程序员的 虎翼老师讲的Redis入门到实战教程，全面透析redis底层原理+redis分布式锁+企业解决方案+redis实战 课程时记录的笔记, 还没学完 , 做一个笔记 , 方便平时翻看
Redis的优惠券秒杀问题（五）全局唯一ID 以及 秒杀下单
金鳞踏雨
11-16 686
我们要讲述的问题大致如下所示，根据黑马程序员视频教程，会分离出Redis关于秒杀问题的核心知识点进行讲解！平价券可以任意购买，而特价券需要秒杀抢购。订单的数据量一般很大，一天可能会有几百万，如果使用自增ID，就很难分库分表了！首先，我们依照黑马的项目来进行分析，在什么情况下要使用到这个全局唯一ID。如果使用自增的话，用户可以根据两笔订单的ID，来判断这段时间内订单的量。：优惠券的库存、开始抢购时间，结束抢购时间。：优惠券的基本信息，优惠金额、使用规则等。，秒内的计数器，支持每秒产生。
【Redis】Redis高级：分布式锁
qq_50675319的博客
09-20 896
上述任务的执行时间我们可以看到，是internalLockLeaseTime / 3，那么这个internalLockLeaseTime又是多少呢？其实这里的internalLockLeaseTime和我们之前提到的看门狗过期时间是同一个时间，也就是30秒，也就是说这里任务的执行时间就是10秒之后，而每当我们执行一次任务之后，任务内部又会再次调用renewExpiration()，也就是说这段任务每隔10秒就会执行一次，刷新当前线程持有锁的有效期，模拟一个锁永不过期的效果，这个任务也就被称为"看门狗"
Redis教程(二十一)：Redis怎么保证缓存一致性
十三月的博客
05-29 922
Redis 的缓存一致性是指在使用 Redis 作为缓存层时，保证缓存中的数据与数据库中的数据保持一致的状态。在分布式系统中，数据一致性是一个重要的问题，因为可能存在多个客户端同时读写同一数据，或者数据在不同节点间需要同步更新。：当数据库中的数据被修改后，相关联的缓存数据需要被相应地更新或失效，以避免返回陈旧的数据。：当缓存的数据被认定为过时（可以是时间过期，或者因为底层数据有变更）时，必须从缓存中移除，以确保下次读取会从后端数据库加载最新数据。：在分布式缓存环境中，相同的数据可能会存储在多个缓存节点上。
redis笔记1
kekexiaomayi的博客
05-28 259
set添加、get获取、mset批量添加、mget批量获取，incr整型的key自增，incrby设置自增的值，setnx添加key并且设置值,setex添加值，指定有效期eg:setex name 5 “xiaoxiao”，为名字加“xiaoxiao”,5秒后过期;HSET添加、修改，HGET查，Hmset批量加、HMGET批量查、HGETALL获取所有等。LPUSH左加、LPOP左取，RPUSH右加、RPOP右取等（左是首，右是尾）无序、不可重复、支持交、并、差集等功能。可排序、不重复，排行榜。
Redis实践记录与总结
最新发布
qq_44031124的博客
05-29 418
紧接着上第二个方案，使用redis数据备份工具redis-dump将缓存数据备份成json文件，再将该json文件中的数据迁移到低版本redis数据库中，对低版本进行rdb文件备份，使用redis rdb tools工具进行分析。Redis缓存数据库设计建议：缓存中的数据不要设置永久性数据，可以定时往数据库中同步数据。上述报错的原因是：当前缓存使用的7版本，而7版本目前redis rdb tools对高版本的rdb文件分析的功能还没有上线，也就是说当前功能不兼容。最近生产环境缓存数据库数据过大（
redis实际应用场景
09-06
Redis具有多种实际应用场景，包括但不限于以下几个方面： 1. 缓存：Redis最常见的用途就是作为缓存层，将经常访问的数据存储在内存中，以提高读取速度和减轻后端数据库的负载。通过使用Redis的高速读写能力，可以...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值