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