秒杀系统-springboot,mysql,redis

叁歲伎倆 2023-07-25 08:41 23阅读 0赞

> 一步步完善的过程

# 1. 环境搭建 #

## 1. 1 目录结构 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdHRsZXdoaXRldmc_size_16_color_FFFFFF_t_70]

## 1.2 sql ##

create table product(
        id            int(12)        not null auto_increment comment 'id',
        product_name  varchar(60)    not null comment '商品名称',
        stock         int(10)        not null comment '库存',
        price         decimal(16,2)  not null comment '单价',
        version       int(10)        not null default 0 comment '版本号,乐观锁',
        primary key (id)
    );
    
    
    -- 购买记录表
    create table purchase_record(
        id             int(12)        not null auto_increment comment ,
        user_id        int(12)        not null comment '用户编号',
        product_id     int(12)        not null comment '商品编号',
        price          decimal(16,2)  not null comment '价格',
        quantity       int(12)        not null comment '数量',
        sum            decimal(16,2)  not null comment '总价',
        purchase_date  timestamp      not null default now() comment '购买日期',
        primary key (id)
    );

service:

@Transactional(propagation = Propagation.REQUIRED, rollbackFor = Exception.class)
        public void seckillbyId(Integer id) {
            Product product = productMapper.getById(id);
            if (product .getStock() > 0) {
                productMapper.decreaseStock(id);
            } else {
                System.out.println("库存不足");
            }
        }

mapper:

@Update("update product set stock=stock-1 where id = #{id}")
    public int decreaseStock(@Param("id") int id);

# 2.理论基础 #

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdHRsZXdoaXRldmc_size_16_color_FFFFFF_t_70 1]  
图片来自:[https://www.cnblogs.com/SteadyJack/p/11228391.html][https_www.cnblogs.com_SteadyJack_p_11228391.html]  
本文实现精简版

1.乐悲观锁原理了解  
[参见][Link 1]  
2.压力测试JMeter基本使用  
[参见][Link 2]  
3.redisTemplate基本使用  
[参见][Link 3]  
4.秒杀系统设计概念  
[秒杀系统架构优化思路][Link 4]  
[秒杀架构参考][Link 5]

# 3.基于Mysql+Mybatis #

## 3.1 基本情况 ##

测试了好几组,一直没有出现超发情况,只能一直不停的修改增加线程数之类的,最后感觉一次减少一个不太行,就把代码改成了以下这样:

@Transactional(propagation = Propagation.REQUIRED, rollbackFor = Exception.class)
        public void seckillbyId(Integer id) {
            Product product = productMapper.getById(id);
            //增加随机数
            int i = new Random().nextInt(10);
            if (product .getStock() > 0) {
                productMapper.decreaseStock(id, i);
            } else {
                System.out.println("库存不足");
            }
    
        }

@Update("update product set stock=stock-#{decrease} where id = #{id}")
        public int decreaseStock(@Param("id") int id, @Param("decrease") int quantity);

原数据库数据:  
![在这里插入图片描述][20200413173338987.png]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdHRsZXdoaXRldmc_size_16_color_FFFFFF_t_70 2]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdHRsZXdoaXRldmc_size_16_color_FFFFFF_t_70 3]  
超发第一次:  
![在这里插入图片描述][20200413173149774.png]  
超发第二次:  
![在这里插入图片描述][20200413173441850.png]  
其实都知道,直接查出来是否为0再减库存的方法肯定是不行,这样做的目的也就是测试一下测试是否可行,以及能否出现超发情况,不然一个错误的方法不能出现超发,后面也不用玩了!

## 3.2 基于乐观锁 ##

乐观锁就是再修改之前看看,当前值是否和我拿到的值是否一样,如果不一样就是说明了,被别人修改了,那么我再去修改这个值可能就会出现并发修改的错误.  
所以每次我要减库存了,我就来看看我改之前拿到的版本号是否被人修改了,即version  
下面是修改过后的关键代码:

@Update("update product set stock=stock-#{decrease} , version = version +1 where id = #{id} and version=#{version}")
        public int decreaseStockByOptimisticLock(@Param("id") int id, @Param("decrease") int quantity, @Param("version") int version);

@Transactional(propagation = Propagation.REQUIRED, rollbackFor = Exception.class)
        public void seckillbyId(Integer id) {
            Product byId = productMapper.getById(id);
            int i = new Random().nextInt(10);
            if (byId.getStock() > 0) {
    //            productMapper.decreaseStock(id, i);
                productMapper.decreaseStockByOptimisticLock(id,i,byId.getVersion());
            } else {
                System.out.println("库存不足");
            }
    
        }

然后进行测试:  
然而:  
![在这里插入图片描述][20200413174813850.png]  
没错,超发了  
问题在哪?  
… 认真看了的应该能够发现,没发现也可以思考一下  
我就不说错误原因了:  
修改后的代码如下:

@Transactional(propagation = Propagation.REQUIRED, rollbackFor = Exception.class)
        public void seckillbyId(Integer id) {
            Product byId = productMapper.getById(id);
            int i = new Random().nextInt(10);
            if (byId.getStock() > 0 && byId.getStock() >= i) {
    //            productMapper.decreaseStock(id, i);
                productMapper.decreaseStockByOptimisticLock(id, i, byId.getVersion());
            } else {
                System.out.println("库存不足");
            }
        }

再来进行测试:  
![在这里插入图片描述][20200413175053392.png]  
哦nice!  
但是这只是第一次,并发是有偶然性的哦!我这样提醒自己  
我把每次的数据库的前后的值都贴出来  
![在这里插入图片描述][2020041317514064.png]  
![在这里插入图片描述][20200413175320920.png]  
再次修改:  
![在这里插入图片描述][20200413175238167.png]  
![在这里插入图片描述][20200413175401851.png]  
奥里给!!!还没出现超发  
再来给个大的:  
![在这里插入图片描述][20200413175441495.png]  
![在这里插入图片描述][20200413175456220.png]  
![在这里插入图片描述][2020041317563347.png]  
???  
我不是设置的5000次吗? 没多大意义的一次测试

## 3.2 基于悲观锁 ##

如何实现悲观锁呢?  
最简单的方法就是加一个synchronized,在一个线程持有锁的时候,其他线程是无法获取到锁的  
代码如下:

@Transactional(propagation = Propagation.REQUIRED, rollbackFor = Exception.class)
        public synchronized void  seckillbyId(Integer id) {
            Product byId = productMapper.getById(id);
            int i = new Random().nextInt(10);
            if (byId.getStock() > 0 && byId.getStock() >= i) {
                productMapper.decreaseStock(id, i);
    //            productMapper.decreaseStockByOptimisticLock(id, i, byId.getVersion());
            } else {
                System.out.println("库存不足");
            }
        }

jconsole表示如下:  
第一次:  
堆内存:

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdHRsZXdoaXRldmc_size_16_color_FFFFFF_t_70 4]  
线程:  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdHRsZXdoaXRldmc_size_16_color_FFFFFF_t_70 5]

跑回去测试了下乐观锁,乐观锁的jconsole表现如下:  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdHRsZXdoaXRldmc_size_16_color_FFFFFF_t_70 6]

# 4.基于Redis #

由上面实现的乐观锁,悲观锁的方式,我们可以看出:  
1.乐观锁其实把压力还是给到了数据库,一查一尝试写  
2.悲观锁对数据库的压力只有一查一准确写  
可见,使用悲观锁对数据库的压力是要小于乐观锁的,但是使用悲观锁,其实就是使减库存操作变成了串行,在性能方面其实是是否堪忧的,而在秒杀环境下,一下子进来那么多请求,完成一次秒杀应该是在很短的时间内的,这样了,我们才想到了,如何能够分摊数据库压力,提高响应速度,增加吞吐量?

**当然这一切都是建立在绝对不能超发的情况下的;**

众所周知,内存的读写速度是要远高于磁盘速度的  
那就用redis做一层缓存呗  
如何优化?

*  读数据库的剩余库存是否可以转移到redis
 *  版本号是否可以转移到redis

很明显,全部全部全部都可以放到redis缓存里;  
其实就是把对mysql的操作放到redis里面,等最后结束秒杀了,就同步回数据库

当然以上以上都是我个人的想法;  
等过一段时间我再来看看,更加完善这一部分的代码书写;

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdHRsZXdoaXRldmc_size_16_color_FFFFFF_t_70]: /images/20230528/83810dededc747e0ba811487229a3cd9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdHRsZXdoaXRldmc_size_16_color_FFFFFF_t_70 1]: /images/20230528/0fd1584f59264ea0b21efeaac98033b2.png
[https_www.cnblogs.com_SteadyJack_p_11228391.html]: https://www.cnblogs.com/SteadyJack/p/11228391.html
[Link 1]: http://www.hollischuang.com/archives/934
[Link 2]: https://www.cnblogs.com/stulzq/p/8971531.html
[Link 3]: https://blog.csdn.net/javaxiaibai0414/article/details/88666453
[Link 4]: https://yq.aliyun.com/articles/69704?utm_campaign=wenzhang&utm_medium=article&utm_source=QQ-qun&utm_content=m_10737
[Link 5]: http://www.mamicode.com/info-detail-2383504.html
[20200413173338987.png]: /images/20230528/fac35e7b097b4e278821e43740534aea.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdHRsZXdoaXRldmc_size_16_color_FFFFFF_t_70 2]: /images/20230528/129897a3048040e9a4151ee3c86ca539.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdHRsZXdoaXRldmc_size_16_color_FFFFFF_t_70 3]: /images/20230528/072d25e8d82c4d7d997df6a2cecdb23c.png
[20200413173149774.png]: /images/20230528/250b30bc00b54813a1a12c854ae2dc39.png
[20200413173441850.png]: /images/20230528/bf166065bdcd46649c1848a114bd2549.png
[20200413174813850.png]: /images/20230528/11768104e0fe4e82b03161cf388181cf.png
[20200413175053392.png]: /images/20230528/d2b2b5ec444d46d993af0865ceeea513.png
[2020041317514064.png]: /images/20230528/f09d560cb423432bb3b9dc654e29975a.png
[20200413175320920.png]: /images/20230528/099526ccfd954498af011640306f555c.png
[20200413175238167.png]: /images/20230528/d7bb0ce3e0424cd8b621bed3c2c64275.png
[20200413175401851.png]: /images/20230528/7cd176444d9145809370d6d03e37fd6d.png
[20200413175441495.png]: /images/20230528/eaf55ebc28cd4193bb33142fd49c207b.png
[20200413175456220.png]: /images/20230528/46c7df6429d5433ea11b7cdbf28c30bf.png
[2020041317563347.png]: /images/20230528/2e94e6b9872c40b3813db60cd3fe53ea.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdHRsZXdoaXRldmc_size_16_color_FFFFFF_t_70 4]: /images/20230528/066ba549bfca4bc7875a9d85fc11c8c8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdHRsZXdoaXRldmc_size_16_color_FFFFFF_t_70 5]: /images/20230528/72cc2d43cae644a0a570c16142a8284b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdHRsZXdoaXRldmc_size_16_color_FFFFFF_t_70 6]: /images/20230528/e08455d3ff7d4645b351510f7ce06e1b.png