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

    像秒杀这种同时需要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后端优化；