高并发秒杀系统实现和优化分析(行级锁优化和具体过程优化)

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/sinat_32133675/article/details/78150920

    像秒杀这种同时需要update和insert操作,update减库存,和insert增加被秒杀的记录。当突发意外,当其中一条执行另一条为执行时,就会产生不匹配的情况,会造成数据丢失。

    这就用到的事务:原子性,一致性,隔离性,持久性

    https://github.com/cdefgab1234/Spring-transaction   事务实现的四中方法。常用后两种,推荐使用最后一种


@Transactional
    /**
     * 使用注解控制事务方法的优点:
     * 1.开发团队达成一致约定,明确标注事务方法的bianch风格
     * 2.保证事务方法的执行时间尽可能短,不要穿插其他的网络操作PRC/HTTP请求,或者剥离到事务方法之外
     * 3.不是所有的方法都需要事务,如只有一条修改操作或者只读操作
     */
    public SeckillExecution executeSeckill(long seckillId, long userPhone, String md5) throws SeckillException, RepeatSeckillException, SeckillCloseException {

        if(md5 == null || !md5.equals(getMd5(seckillId))){
            throw new SeckillCloseException("seckill data rewrite");
        }
        //执行秒杀逻辑减库存+记录秒杀逻辑
        Date nowTime = new Date();
        //减库存
        try {

            int updateCount = seckillDao.reduceNumber(seckillId,nowTime);
            if(updateCount <=0){
                //没有更新到记录,秒杀结束
                throw new SeckillCloseException("seckill is closed!");
            }else {
                //记录秒杀逻辑
                int insertCount = successKilledDao.insertSuccessKilled(seckillId,userPhone);
                if(insertCount<=0){
                    //重复秒杀
                    throw new RepeatSeckillException("seckill repeat!");
                }else {
                    //秒杀成功
                    SuccessKilled successKilled = successKilledDao.queryByIdWithSeckill(seckillId,userPhone);
                    return new SeckillExecution(seckillId, SeckillStatEnum.SUCCESS,successKilled);
                }
            }
        }catch (SeckillCloseException e1){
            throw e1;
        }catch (RepeatSeckillException e2){
            throw e2;
        }catch (Exception e){
            logger.error(e.getMessage(),e);
            //所有编译期异常转换成运行期异常
            throw new SeckillException("seckill inner error"+e.getMessage());
        }
    }

附上一张springMVC的运行流程:


面向Resultful接口编程类的实现:


举个例子:

@RequestMapping(value="/list",method = RequestMethod.GET)
    public String list(Model model){
        //获取列表页
        List<Seckill> list = seckillService.getSeckillList();
        model.addAttribute("list",list);
        //list.jsp+model =modelanfview
        return "list";///WEB-INF/"list".jsp
    }
请求重定向:http://www.cnblogs.com/CodeGuy/archive/2012/02/13/2349970.html(未登录是保护信息使用一下)

/**
     * forward是服务器请求资源,服务器直接访问目标地址的URL,把那个URL的响应内容读取过来,然后把这些内容再发给浏览器.浏览器根本不知道服务器发送的内容从哪里来的,所以它的地址栏还是原来的地址.
       redirect是服务端根据逻辑,发送一个状态码,告诉浏览器重新去请求那个地址.所以地址栏显示的是新的URL.
     * @param seckillId
     * @param model
     * @return
     */
    @RequestMapping(value = "/{seckillId}/detail",method = RequestMethod.GET)
    public String detail(@PathVariable("seckillId") Long seckillId, Model model){
        if(seckillId == null){
           return "redirect:/seckill/list";
        }
        Seckill seckill = seckillService.getById(seckillId);
        if(seckill == null){
            return "forward:/seckill/list";
        }
        model.addAttribute("seckill",seckill);
        return "detail";
    }

通过这次项目实践,了解了CDN的使用,像前端的jquery,css的jar包,都在用cdn的方式加载,方便快捷。但是需要在网络环境下调试,还有CDN只能访问静态资源(局限性),像BTA都会有自己搭建的CDN,小型互联网公司都会租用电信网通的CDN。加载CDN时,不会访问后端服务器。

返回json得序列话设计:

@ResponseBody实现

//ajax ,json暴露秒杀接口的方法
    @RequestMapping(value = "/{seckillId}/exposer",
            method = RequestMethod.GET,
            produces = {"application/json;charset=UTF-8"})
    @ResponseBody
    public SeckillResult<Exposer> exposer(@PathVariable("seckillId") Long seckillId)
    {
        SeckillResult<Exposer> result;
        try{
            Exposer exposer=seckillService.exportSeckillUrl(seckillId);
            result=new SeckillResult<Exposer>(true,exposer);
        }catch (Exception e) {
            e.printStackTrace();
            result=new SeckillResult<Exposer>(false,e.getMessage());
        }

        return result;
    }

下面是高并发的优化:

都说mysql的效率低,其实并不是。一条update语句1秒可以抗住4W的并发,这其实不算低了;那么效率是丢在了哪里呢?


GC:就是java虚拟机回收垃圾,释放内存的过程。这会终端所用的业务,也就是java代码,大概需要几十毫秒。不是每次操作都会有GC产生,但它一定会发生。

这里还会有一个事务的行级锁的问题,当一个事务在执行时,它会把相关的功能锁住。当它commit或者rollback之后,后面的事务才能继续执行,以次类推,会造成很大的拥堵。

优化的方向:减少行级锁持有的时间。


这里注意一下:如何减少行级锁持有时间

      已秒杀系统为例:先执行insert,后执行update,行级锁持有时间只在update前后;

                                  若先执行update,在执行insert,那么行级锁的持有时间就变成了update到第二个update之间的update和insert时间,相当于多包含了insert的网络延迟和GC。

      同一事务,先后顺序确实有差异(还挺大)。

   把客户端逻辑放到Mysql服务端,避免网络延迟和GC的影响;


卧槽,我第一次觉得存储过程这么有用。第一种要改源码,效率不用说,一般团队干不了。第二种就不一样了,存储过程,谁不会写?


这里介绍了行级锁的优化方法,下一张介绍redis后端优化;





没有更多推荐了,返回首页