从零开始学习秒杀项目

构思了很多种讲述这个简易版的秒杀项目的思路，比如按照功能分类，按照项目亮点串起来讲述，总觉得不适合基础薄弱的同学来学习，所以本项目按照从搭建开始，过程中需要什么来学习什么。

技术栈

SpringBoot+mybatisPlus，MySQL,Redis,RabbitMQ

项目地址

ma/seckill

亮点

1.自定义注解（Spring AOP）

2.用户密码两次MD5加密

第一次MD5加密：防止用户明文密码在网络进行传输

第二次MD5加密：防止数据库被盗，避免通过MD5反推出密码，双重保险

3.redis分布式锁保证秒杀业务场景下的正确性

4.秒杀操作后的秒杀成功信息进入RabbitMQ进行排队

项目代码结构图

准备

创建SpringBoot项目，写入Maven文件，导入sql文件。

数据库介绍

使用MYSQL

goods代表货物信息表

order_info订单详情表

seckill_good秒杀商品表

seckill_order秒杀商品订单表

user用户表

Redis服务启动

这里使用的是Redis-windows版本，无密码

RabbitMQ服务启动

如果你不会安装RabbitMQ，请查看windows环境下安装RabbitMQ（超详细）_windows安装rabbitmq-CSDN博客

http://localhost:15672/#/保证本机RabbitMQ服务启动（账号是默认账号guest/guest）

http://localhost:15672/#/

Coding

用户登录模块

对应LoginController.java

一共有两个方法，一个是界面跳转方法，略过

    @RequestMapping("/do_login")@ResponseBodypublic Result<String> doLogin(@Valid LoginParam loginParam, HttpServletResponse response){System.out.println(loginParam);//登陆String token = userService.login(response, loginParam);return Result.success(token);}

首先来说一下整个方法的返回值Result.java

public class Result<T> {private int code;private String msg;private T data;private Result(T data) {this.code = CodeMsg.SUCCESS.getCode();this.msg = CodeMsg.SUCCESS.getMsg();this.data = data;}public boolean isSuccess(){return this.code==CodeMsg.SUCCESS.getCode();}public static <T> Result<T> success(T data){return new Result<T>(data);}public static <T> Result<T> error(CodeMsg codeMsg){return new Result<T>(codeMsg);}private Result(int code, String msg) {this.code = code;this.msg = msg;}private Result(CodeMsg codeMsg) {if(codeMsg != null) {this.code = codeMsg.getCode();this.msg = codeMsg.getMsg();}}public int getCode() {return code;}public void setCode(int code) {this.code = code;}public String getMsg() {return msg;}public void setMsg(String msg) {this.msg = msg;}public T getData() {return data;}public void setData(T data) {this.data = data;}
}

里面有三个变量，分别代表着结果代码，结果信息，结果中返回的数据，T代表泛型的意思，不懂的可以百度；CodeMsg代表的具体定义的一些成功和异常信息。

接下来我们再返回LoginController里面的doLogin方法，可以注意到在函数参数中使用了@Valid注解，代表着LoginParam需要进行参数检查，我们进入LoginParam.java

import com.lgc.SeckillProject.vaildator.IsMobile;
import lombok.Getter;
import lombok.Setter;
import lombok.ToString;
import org.hibernate.validator.constraints.Length;import javax.validation.constraints.NotNull;@Getter
@Setter
@ToString
public class LoginParam {@NotNull(message = "手机号不能为空")@IsMobileprivate String mobile;@NotNull@Length(min = 23,message = "密码长度需要在7个字以内")private String password;
}

上面的代码特意粘贴了使用注解来源于哪个包，明确一下注解的来源。

代码中的两个字段mobile和password两个字段分别用@NotNull注解修饰，意思是两个字段传入的时候不允许为空。

另外password对字段的长度进行了限制.

拓展：

我们还注意到他使用了@IsMobile注解，这是一个自定义的注解，也是本项目中的一个亮点。

我们需要自定义注解，首先创建一个自定义注解类

@Target({METHOD,FIELD,ANNOTATION_TYPE,CONSTRUCTOR,PARAMETER}) //注解的作用范围 ：方法，字段、枚举的常量，注解，构造函数，方法参数
@Retention(RetentionPolicy.RUNTIME)   //注解的生命周期：默认是class,RUNTIME：运行时存在。RUNTIME>class>source
@Documented   //如果一个注解@B，被@Documented标注，那么被@B修饰的类，生成文档时，会显示@B。如果@B没有被@Documented标准，最终生成的文档中就不会显示@B。
@Constraint(validatedBy = {IsMobileValidator.class})//自定义约束
public @interface IsMobile {boolean required() default true;String message() default "手机号码格式错误";Class<?>[] groups() default {};Class<? extends Payload>[] payload() default {};}

从上面看，有很多陌生的注解，我们一个一个来分析

首先是@Target注解，里面写入了这个注解的使用范围，包括可以在方法上使用，字段、枚举的常量，注解，构造函数，方法参数

@Retention(RetentionPolicy.RUNTIME)注解的生命周期，一般是RUNTIME，默认是class;RUNTIME>CLASS>SOURCE

@Document .如果一个注解@B，被@Documented标注，那么被@B修饰的类，生成文档时，会显示@B。如果@B没有被@Documented标准，最终生成的文档中就不会显示@B

@Constraint 自定义约束，IsMobileValidator.class是自定义的约束类

自定义注解中有几个方法，并且每个方法中都有默认的值。

接下来我们来看一下注解中自定义约束类IsMobileValidator.java

public class IsMobileValidator implements ConstraintValidator<IsMobile,String> {private boolean required=false;@Overridepublic void initialize(IsMobile constraintAnnotation) {required=constraintAnnotation.required();}@Overridepublic boolean isValid(String value, ConstraintValidatorContext context) {if (required){return VaildatorUtil.isMobile(value);}else{if (StringUtils.isEmpty(value)){return true;}else{return VaildatorUtil.isMobile(value);}}}
}

首先实现接口ConstraintValidator,参数为自定义注解和String

重写里面的initialize方法还有isValid方法，require代表的是需不需要进行验证，isValid是验证方法，如果是需要的验证的话，调用isValid方法，isValid里面又使用ValidatorUtil.isMobild方法,这个方法的内部是使用正则表达式进行实现的。

至此，自定义注解讲解完成。

我们返回LoginController继续，我们来看一下userService.login这个方法，进入UserServiceImpl中login方法。

我们来分析一下上面的红框中的代码，为了防止从浏览器中输入的密码在网络中明文传输，我们使用了MD5进行加密，在从浏览器的输入中获取密码后加入“盐”使用MD5.formPassToDBPass进行加密处理，然后再与数据库中已加密的密码进行比较。

以上是加密的细节。

返回UserServiceImpl，继续看login方法后半段生成cookie部分

使用UUIDUtil工具类生成随机的token ,进入addCookie方法

//生成cookie
String token = UUIDUtil.uuid();
addCookie(response,token,user);
return token;

在Cookie方法中，把生成的token作为key的后半段，UserKey.token作为前半段，拼接构成key值，user对象作为value值传入Redis,并且生成一个Cookie对象放入response中。

private void addCookie(HttpServletResponse response,String token,User user){redisService.set(UserKey.token,token,user,UserKey.TOKEN_EXPIRE);Cookie cookie = new Cookie(COOKI_NAME_TOKEN, token);cookie.setMaxAge(UserKey.TOKEN_EXPIRE);cookie.setPath("/");response.addCookie(cookie);}

这里重点讲解一下redisService.set方法的内部逻辑

/*** 设置对象** @param prefix 对象Prefix* @param key    键* @param value  值* @param exTime 过期时间* @param <T>    返回类型* @return*/public <T> boolean set(KeyPrefix prefix,String key,T value,int exTime){String str = beanToString(value);if (str==null || str.length() <= 0){return false;}//生成唯一keyString realKey = prefix.getPrefix() + key;//设置过期时间if (exTime<=0){stringRedisTemplate.opsForValue().set(realKey,str);}else{return stringRedisTemplate.opsForValue().setIfAbsent(realKey,str,exTime, TimeUnit.SECONDS);}return true;}

为了保证整个秒杀业务中商品数量的正确性，关键的一个步骤是并发场景下，锁的竞争，在这里使用了redis的分布式锁机制，也就是setIfAbsent这个方法，我认为也是整个项目的关键之一。在本文中的最后部分《redis分布式锁解析》详细介绍一下这个东西。

订单模块

对应orderController.java

订单模块的控制层只包含一个方法，info 方法，参数为user以及订单号，返回值为订单详情。

该模块大多数为增删改查以及简单的业务逻辑，较为简单，自己顺着代码看看就可以

货物模块

对应GoodsController.java

首先针对list方法进行分析。

为了应对在SpringBoot中的高并发及优化访问速度，我们一般会把页面上的数据查询出来，然后放到redis中进行缓存，减少数据库的压力。如果再进行改进的话，可以对整个界面进行缓存。

@RequestMapping("/list")@ResponseBodypublic String list(Model model, HttpServletRequest request, HttpServletResponse response){//取缓存String html = redisService.get(GoodsKey.getGoodsList, "", String.class);if (!StringUtils.isEmpty(html)){return html;}//获取数据绑定到modelList<GoodsVo> goodsVos = goodService.listGoodVo();model.addAttribute("goodsVos",goodsVos);WebContext ctx = new WebContext(request, response, request.getServletContext(), request.getLocale(), model.asMap());//手动渲染html = thymeleafViewResolver.getTemplateEngine().process("goods_list", ctx);if (!StringUtils.isEmpty(html)){redisService.set(GoodsKey.getGoodsList,"",html,60);}return html;}

goodsDetail和detailStatic思路也是一样的，无非就是添加了秒杀状态还有倒计时这俩，思路和上面的代码是一致的。自己顺着代码理一遍就可以

秒杀模块

对应模块SeckillController.java

实现了InitializingBean接口，需要重写afterPropertiesSet方法，系统启动后，进行初始化，将热点数据放入redis中。

这里在方法里还定义了一个map,我们知道map的存储位置是内存中，所以我们将秒杀的商品的Id放入内存中，查询速度会飞快。

下面介绍一下秒杀接口1.0以及改进版本，从一开始的QPS793经过优化后QPS1658

首先是1.0版本 QPS:793 * 线程：5000 * 10 * 进行秒杀

@RequestMapping("/do_seckill")public String seckill(Model model, User user, @RequestParam("goodsId")long goodsId){model.addAttribute("user",user);if (user==null){return "login";}//库存判断GoodsVo goodsVo = goodsService.getGoodsVoById(goodsId);int stock = goodsVo.getStockCount();if (stock<=0){model.addAttribute("ErrorMsg", CodeMsg.MIAO_SHA_OVER.getMsg());return "seckill_fail";}//判断是否秒杀到了SeckillOrder order = orderService.getOrderByUserIdGoodsId(user.getId(), goodsId);if (order!=null){model.addAttribute("ErrorMsg",CodeMsg.REPEATE_MIAOSHA.getMsg());return "seckill_fail";}//减库存下订单，写入秒杀订单OrderInfo orderInfo = seckillService.seckill(user, goodsVo);model.addAttribute("orderInfo",orderInfo);model.addAttribute("goods",goodsVo);return "order_detail";}

核心是将处理好的数据放到model,界面查询速度偏慢

2.0版本 * QPS:1206 * 线程：5000 * 10 * 订单页面静态化

@RequestMapping(value = "/seckill",method = RequestMethod.POST)@ResponseBodypublic Result<OrderInfo> seckillStatic(User user,@RequestParam("goodsId")long goodsId){if (user==null){return Result.error(CodeMsg.SESSION_ERROR);}//判断库存GoodsVo goods = goodsService.getGoodsVoById(goodsId);int stock=goods.getStockCount();if (stock<=0){return Result.error(CodeMsg.MIAO_SHA_OVER);}//判断是否已经秒杀到了SeckillOrder order = orderService.getOrderByUserIdGoodsId(user.getId(), goodsId);if (order!=null){return Result.error(CodeMsg.REPEATE_MIAOSHA);}//减少库存，写入秒杀订单OrderInfo orderInfo = seckillService.seckill(user, goods);return Result.success(orderInfo);}

整体的流程和1.0没有区别，区别在于将最后的结果封装在Result中了。速度还可以再提升

3.0版 * QPS:1658 * 线程：5000 * 10 * 加入消息队列

@RequestMapping(value = "/{path}/seckill_mq",method = RequestMethod.POST)@ResponseBodypublic Result<Integer> seckillMq(User user, @RequestParam("goodsId")long goodsId, @PathVariable("path")String path){if (user==null){return Result.error(CodeMsg.SESSION_ERROR);}//验证pathboolean checkPath = seckillService.checkPath(user, goodsId, path);if (!checkPath){return Result.error(CodeMsg.REQUEST_ILLEGAL);}//内存标记，减少Redis访问Boolean over = localOverMap.get(goodsId);if (over){return Result.error(CodeMsg.MIAO_SHA_OVER);}//预减库存Long stock = redisService.decr(GoodsKey.getSeckillGoodStock, "" + goodsId);if (stock<0){localOverMap.put(goodsId,true);return Result.error(CodeMsg.MIAO_SHA_OVER);}//判断是否秒杀到了SeckillOrder order = orderService.getOrderByUserIdGoodsId(user.getId(), goodsId);if (order!=null){return Result.error(CodeMsg.REPEATE_MIAOSHA);}//压入消息队列中//入队SeckillMessage sm = new SeckillMessage();sm.setUser(user);sm.setGoodsId(goodsId);sender.sendSeckillMessage(sm);return Result.success(0);//排队中}

3.0版本一个是引入了本地map减少了Redis的访问，另外使用了预减库存，秒杀成功后将秒杀成功信息发送到RabbitMQ中，进入队列中排队。

从代码中可以看出预减成功后也只是进入到了RabbitMQ中进行排队，不至于阻塞，至于最后入库，还需要对队列进行监听。

值得说一点的是，秒杀接口操作的层次仅仅只在Redis中，所有操作的数据都在Redis中，所以此过程不存在与数据库的任何操作，也就是说你如果在秒杀过程中失败了，不会影响到数据库中的数据，这是极为巧妙的，也是值得学习的，只有当秒杀成功后，秒杀成功的消息放入MQ，并且MQ监听到的时候，此时监听到的信息才会真正的创建订单并存入数据库。

 @RabbitListener(queues = MQConfig.SECKILL_QUEUE)public void receive(String message){log.info("receive message:"+message);SeckillMessage sm = redisService.stringToBean(message, SeckillMessage.class);User user = sm.getUser();long goodsId = sm.getGoodsId();GoodsVo goods = goodsService.getGoodsVoById(goodsId);int stock=goods.getStockCount();if (stock<=0){return;}//判断是否秒杀到了SeckillOrder order = orderService.getOrderByUserIdGoodsId(user.getId(), goodsId);if (order!=null){return;}//减库存 下订单 写入秒杀订单seckillService.seckill(user,goods);}

上面的方法是RabbitMQ监听队列SECKILL_QUEUE,按照顺序，从队列中读取数据同步数据库操作。

/*** 客户端轮询查询是否下单成功* orderId：成功* -1：秒杀失败* 0： 排队中*/@RequestMapping(value = "/result",method = RequestMethod.GET)@ResponseBodypublic Result<Long> seckillResult(@RequestParam("goodsId")long goodsId,User user){if (user==null){return Result.error(CodeMsg.USER_NO_LOGIN);}long result = seckillService.getSeckillResult(user.getId(), goodsId);return Result.success(result);}

前端轮训查询是否下单成功，最终查询的是数据库中的数据，而不是Redis中的数据。

/*** 获取秒杀地址* 自定义接口限流：5秒内最多访问5次，并需要为登录状态* @param user* @param goodsId* @return*/@AccessLimit(seconds = 5,maxCount = 5,needLogin = true)@RequestMapping(value = "/path",method = RequestMethod.GET)@ResponseBodypublic Result<String> getSeckillPath(User user,@RequestParam("goodsId")long goodsId){if (user==null){return Result.error(CodeMsg.USER_NO_LOGIN);}String path = seckillService.createPath(user, goodsId);return Result.success(path);}

上面是获取秒杀地址的接口，因为主要的并发压力在这个接口，所以需要对这个接口进行限流。

核心点在@AccessLimit这个自定义注解中，来看一下自定义注解的定义

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface AccessLimit {int seconds();int maxCount();boolean needLogin() default true;
}

注解不解释了，里面定义了三个方法，seconds(),maxCount(),needLogin(),除了第三个方法从字面意思上能知道是干啥用的，其余头俩都不清楚，这就引出了Spring一个很重要的特性，面向切面编程。

找到AccessInterceptor.java这个类，实现HandlerInterceptor接口，实现preHandle方法

@Overridepublic boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {if (handler instanceof  HandlerInterceptor){//获取用户，并保存User user = getUser(request, response);UserContext.setUser(user);//获取限流注解HandlerMethod hm = (HandlerMethod) handler;AccessLimit accessLimit = hm.getMethodAnnotation(AccessLimit.class);if (accessLimit==null){return true;}//自定义接口限流：时间、访问数、是否需要登录//在conttoller方法上加上@AccessLimit(second=5,maxCount=5,needLogin=true)int seconds = accessLimit.seconds();int maxCount = accessLimit.maxCount();boolean needLogin = accessLimit.needLogin();String key = request.getRequestURI();if (needLogin){if (user==null){render(response, CodeMsg.SESSION_ERROR);return false;}key+="_"+user.getId();}else{//do nothing}//根据限流键值获取缓存AccessKey ak = AccessKey.withExpire();Integer count = redisService.get(ak, key, Integer.class);if (count==null){redisService.set(ak,key,1,seconds);} else if (count<maxCount) {redisService.incr(ak,key);}else{render(response,CodeMsg.ACCESS_LIMIT_REACHED);return false;}}return true;}

Spring中AOP的概念将在上面的代码中体现的淋漓尽致，首先是if判断是否继承自HandlerInterceptor,然后从request中获取token,进而得到当前的用户，得到用户后与ThreadLocal进行绑定，Threadlocal的底层是一个Map的结构。

随后我们基于当前的handler处理器得到方法的注解，通过这个对象的获取，我们可以拿到注解中各个参数的值。

如果说注解标记的方法需要登录后才能使用，恰巧获取的当前用户为空，需要返回给界面一些提示信息，比如像下面代码这样写

/*** 把提示返回给客户端* @param response* @param cm* @throws Exception*/private void render(HttpServletResponse response, CodeMsg cm) throws Exception{response.setContentType("application/json;charset=UTF-8");OutputStream out = response.getOutputStream();String str = JSON.toJSONString(Result.error(cm));out.write(str.getBytes("UTF-8"));out.flush();out.close();}

之后我们需要根据限流键值对从redis中获取此时这个方法目前已被访问的次数。

值得一提的是redisService.incr以及redisService.decr都是原子方法。

至此切面写完了，我们需要把切面注入到Spring中

来到WebConfig.java，实现WebMvcConfigurer接口,需要重写addArgumentResolvers还有addInterceptors。

addInterceptors这个方法是将自定义的accessInterceptor注册进来就可以

@Overridepublic void addInterceptors(InterceptorRegistry registry) {registry.addInterceptor(accessInterceptor);}

addArgumentReslvers这个是对Controller层传入的参数进行处理，将处理好的参数传给Controller里面的方法。详情请查看《WebMvcConfigurer中addArgumentResolvers方法的使用》

我们在这里使用的是自己定义的UserArgumentResolver.java这个类。

@Service
public class UserArgumentResolver implements HandlerMethodArgumentResolver {@Overridepublic boolean supportsParameter(MethodParameter parameter) {Class<?> clazz = parameter.getParameterType();return clazz== User.class;}@Overridepublic Object resolveArgument(MethodParameter parameter, ModelAndViewContainer mavContainer, NativeWebRequest webRequest, WebDataBinderFactory binderFactory) throws Exception {return UserContext.getUser();}
}

我们来简单介绍一下这个实现了HandlerMethodArgumentResolver接口的自定义方法，只有参数是User.class时才会生效，生效后会返回一个User对象。要想深入理解可参考：

https://blog.csdn.net/ocean35/article/details/105892788

结束----

自定义全局异常

自定义异常类在项目中会经常遇到，主要帮助用户抛出自定义的异常，方便用户理解。

public class GlobalException extends  RuntimeException{private static final long serialVersionUID=1L;private CodeMsg cm;public GlobalException(CodeMsg cm){super(cm.toString());this.cm=cm;}public CodeMsg getCm(){return cm;}
}

因为继承自RuntimeException所以必须有个super方法。

Redis配置类

这里使用了Jedis的直接读且application.properties文件的方法，比较新颖，如果以后在项目中碰到业务场景需加入redis并且要求配置简便的情况下，可以考虑这种

首先是RedisConfig这个配置类，主要是与application.properties中的配置字段对应上。

@Data
@Component
@ConfigurationProperties(prefix = "redis")
public class RedisConfig {private String host;private int port;private int timeout;private String password;private int poolMaxTotal;private int poolMaxIdle;private int poolMaxWait;
}

@ConfigurationProperties(prefix="redis")这与application.properties相对应。

接下来是jedisPool创建操作

@Service
public class RedisPoolFactory {@Autowiredprivate RedisConfig redisConfig;@Beanpublic JedisPool JedisPoolFactory(){JedisPoolConfig poolConfig = new JedisPoolConfig();poolConfig.setMaxIdle(redisConfig.getPoolMaxIdle());poolConfig.setMaxTotal(redisConfig.getPoolMaxTotal());poolConfig.setMaxWaitMillis(redisConfig.getPoolMaxWait()*1000);JedisPool jp = new JedisPool(poolConfig, redisConfig.getHost(), redisConfig.getPort(),redisConfig.getTimeout() * 1000, redisConfig.getPassword(), 0);return jp;}
}

核心的一点就是创建JedisPool操作。

redis分布式锁解析

知识点

setIfAbsent(key,value,时长，时长单位):设置之前先判断key值是否存在

setIfAbsent 是redis(setnx)在java中的用法

思路

1.根据秒杀的业务场景，我们需要对秒杀商品的库存数生成一个锁，更改库存数的时候先判断库存锁是否有效和存在

2.如果库存锁存在返回一个错误提示

3.如果库存锁不存在，对库存数量进行操作

4.执行完整个逻辑后删除库存锁

锁的设计

stringRedisTemplate.opsForValue().setIfAbsent(realKey,str,exTime, TimeUnit.SECONDS);

realKey作为key

str作为value

exTime代表过期时间

TimeUnit.SECONDs代表时间单位

WebMvcConfigurer中addArgumentResolvers方法的使用

在Springboot中的WebMvcConfigurer接口在Web开发中经常被使用，例如配置拦截器、配置ViewController、配置Cors跨域等。

本文主要讲解另一个方法：addArgumentResolvers()在实例中的应用。

一、方法作用该方法可以用在对于Controller中方法参数传入之前对该参数进行处理。然后将处理好的参数在传给Controller中的方法。官方API文档解释：添加解析器以支持自定义控制器方法参数类型。这不会覆盖对解析处理程序方法参数的内置支持。要自定义对参数解析的内置支持，请RequestMappingHandlerAdapter直接配置。

二、场景描述在权限场景中，通常会有要求用户登录之后才能访问的场景。对于这些问题可以多种解决方案，如：使用Cookie+Session的会话控制、使用拦截器、使用SpringSecurity或shiro等权限管理框架等。这里使用Cookie+Session处理。处理的逻辑为：用户第一次登录之后会得到一个cookie，在以后每次的访问过程中都会携带Cookie进行访问。在后台的Controller中对于需要登录权限的访问接口都要先获取Cookie中的Token，再使用Token从session中获取用户登录信息来判断用户登录情况决定是否放行。