在前两篇文章的介绍下，我们完成了防止超卖商品和抢购接口的限流，已经能够防止大流量把我们的服务器直接搞炸，这篇文章中，我们要开始关心一些细节问题。对于稍微懂点电脑的，点击F12打开浏览器的控制台，就能在点击抢购按钮后，获取我们抢购接口的链接（手机APP等其他客户端可以抓包来拿到）。一旦拿到了抢购的链接，只要稍微写点爬虫代码，模拟一个抢购请求，就可以不通过点击下单按钮，直接在代码中请求我们的接口，完成下单。他们只需要在抢购时刻的0毫秒，开始不间断发起大量请求，绝对比大家在APP上点抢购按钮要快，毕竟人的速度有限，更别说APP说不定还要经过几层前端验证才会真正发出请求。本篇我们从两个方面对所出现的问题来进行相关限制：抢购接口隐藏和单用户限制频率。

抢购接口隐藏

如果在秒杀活动活动开始前不知道具体的接口，那是不是就不能发起请求了？所以我们可以将抢购接口进行隐藏，抢购接口隐藏（接口加盐）的具体做法：

每次点击秒杀按钮，先从服务器获取一个秒杀验证值（接口内判断是否到秒杀时间）；
Redis以缓存用户ID和商品ID为Key，秒杀地址为Value缓存验证值；
用户请求秒杀商品的时候，要带上秒杀验证值进行校验。

其实这种方式可以防住的是直接请求接口的人，但是只要把脚本写复杂一点，先去请求一个验证值，再立刻请求抢购，也是能够抢购成功的。不过请求验证值接口，也需要在抢购时间开始后，才能请求接口拿到验证值，然后才能申请抢购接口。理论上来说在访问接口的时间上受到了限制，并且我们还能通过在验证值接口增加更复杂的逻辑，让获取验证值的接口并不快速返回验证值，进一步拉平普通用户和恶意请求的下单时刻。所以接口加盐还是有用的！下面我们就实现一种简单的加盐接口代码，抛砖引玉。

接口加盐实现

代码还是使用之前的项目，我们在其上面增加两个接口：获取验证值接口和携带验证值下单接口。之前我们只有两个表，一个stock表放库存商品，一个stockOrder订单表，放订购成功的记录。但是这次涉及到了用户，所以我们新增用户表，并且添加一个用户王二。并且在订单表中，不仅要记录商品id，同时要写入用户id。

创建SQL语句

-- ----------------------------
-- Table structure for stock
-- ----------------------------
DROP TABLE IF EXISTS `stock`;
CREATE TABLE `stock` (`id` int(11) unsigned NOT NULL AUTO_INCREMENT,`name` varchar(50) NOT NULL DEFAULT '' COMMENT '名称',`count` int(11) NOT NULL COMMENT '库存',`sale` int(11) NOT NULL COMMENT '已售',`version` int(11) NOT NULL COMMENT '乐观锁，版本号',PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8;-- ----------------------------
-- Records of stock
-- ----------------------------
INSERT INTO `stock` VALUES ('1', 'iphone', '50', '0', '0');
INSERT INTO `stock` VALUES ('2', 'mac', '10', '0', '0');-- ----------------------------
-- Table structure for stock_order
-- ----------------------------
DROP TABLE IF EXISTS `stock_order`;
CREATE TABLE `stock_order` (`id` int(11) unsigned NOT NULL AUTO_INCREMENT,`sid` int(11) NOT NULL COMMENT '库存ID',`name` varchar(30) NOT NULL DEFAULT '' COMMENT '商品名称',`user_id` int(11) NOT NULL DEFAULT '0',`create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '创建时间',PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;-- ----------------------------
-- Records of stock_order
-- ------------------------------ ----------------------------
-- Table structure for user
-- ----------------------------
DROP TABLE IF EXISTS `user`;
CREATE TABLE `user` (`id` bigint(20) NOT NULL AUTO_INCREMENT,`user_name` varchar(255) NOT NULL DEFAULT '',PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8mb4;-- ----------------------------
-- Records of user
-- ----------------------------
INSERT INTO `user` VALUES ('1', '王二');

获取验证值接口

该接口要求传用户id和商品id，返回验证值。我们在Controller中添加方法：

/*** 获取验证值* @return*/
@RequestMapping(value = "/getVerifyHash", method = {RequestMethod.GET})
@ResponseBody
public String getVerifyHash(@RequestParam(value = "sid") Integer sid,@RequestParam(value = "userId") Integer userId) {String hash;try {hash = userService.getVerifyHash(sid, userId);} catch (Exception e) {LOGGER.error("获取验证hash失败，原因：[{}]", e.getMessage());return "获取验证hash失败";}return String.format("请求抢购验证hash值为：%s", hash);
}

在UserService中添加方法：

@Override
public String getVerifyHash(Integer sid, Integer userId) throws Exception {// 验证是否在抢购时间内LOGGER.info("请自行验证是否在抢购时间内");// 检查用户合法性User user = userMapper.selectByPrimaryKey(userId.longValue());if (user == null) {throw new Exception("用户不存在");}LOGGER.info("用户信息：[{}]", user.toString());// 检查商品合法性Stock stock = stockService.getStockById(sid);if (stock == null) {throw new Exception("商品不存在");}LOGGER.info("商品信息：[{}]", stock.toString());// 生成hashString verify = SALT + sid + userId;String verifyHash = DigestUtils.md5DigestAsHex(verify.getBytes());// 将hash和用户商品信息存入redisString hashKey = CacheKey.HASH_KEY.getKey() + "_" + sid + "_" + userId;stringRedisTemplate.opsForValue().set(hashKey, verifyHash, 3600, TimeUnit.SECONDS);LOGGER.info("Redis写入：[{}] [{}]", hashKey, verifyHash);return verifyHash;
}

Redis的Cache常量枚举类CacheKey如下：

public enum CacheKey {HASH_KEY("miaosha_v1_user_hash"),LIMIT_KEY("miaosha_v1_user_limit");private String key;private CacheKey(String key) {this.key = key;}public String getKey() {return key;}
}

代码整体来说比较简单，拿到用户id和商品id后，检查商品和用户信息是否在表中存在，并且会验证现在的时间（我这里为了简化，只是写了一行LOGGER，大家可以根据需求自行实现）。在这样的条件过滤下，才会给出hash值，并且将Hash值写入了Redis中，缓存3600秒（1小时），如果用户拿到这个hash值一小时内没下单，则需要重新获取hash值。
这里有一个问题需要大家思考一下：为什么verify 除了使用商品id和用户id还要额外加一个SALT 再使用MD5加密得到verifyHash ？

String verify = SALT + sid + userId;

其实用户id并不一定是用户不知道的（就比如我这种用自增id存储的，肯定不安全），而商品id，万一也泄露了出去，那么别人就可以通过md5直接就hash算出来。随意这里给前面加了前缀，也就是一个salt（盐），相当于给这个固定的字符串撒了一把盐，写死在了代码里。这样只要不猜到这个盐，就没办法算出来verifyHash值。当然，我这里只是其中一种方式，大家在使用的时候可以依据自己的方式，比如可以结合时间戳等来保证verifyHash不容易被计算出来。

携带验证值下单接口

用户在前台拿到了验证值后，点击下单按钮，前端携带着特征值，即可进行下单操作。Controller中添加要求验证的抢购接口：

@RequestMapping(value = "/createOrderWithVerifiedUrl", method = {RequestMethod.GET})
@ResponseBody
public String createOrderWithVerifiedUrl(@RequestParam(value = "sid") Integer sid,@RequestParam(value = "userId") Integer userId,@RequestParam(value = "verifyHash") String verifyHash) {int stockLeft;try {stockLeft = orderService.createVerifiedOrder(sid, userId, verifyHash);LOGGER.info("购买成功，剩余库存为: [{}]", stockLeft);} catch (Exception e) {LOGGER.error("购买失败：[{}]", e.getMessage());return e.getMessage();}return String.format("购买成功，剩余库存为：%d", stockLeft);
}

OrderService中添加方法：

@Override
public int createVerifiedOrder(Integer sid, Integer userId, String verifyHash) throws Exception {// 验证是否在抢购时间内LOGGER.info("请自行验证是否在抢购时间内,假设此处验证成功");// 验证hash值合法性String hashKey = CacheKey.HASH_KEY.getKey() + "_" + sid + "_" + userId;String verifyHashInRedis = stringRedisTemplate.opsForValue().get(hashKey);if (!verifyHash.equals(verifyHashInRedis)) {throw new Exception("hash值与Redis中不符合");}LOGGER.info("验证hash值合法性成功");// 检查用户合法性User user = userMapper.selectByPrimaryKey(userId.longValue());if (user == null) {throw new Exception("用户不存在");}LOGGER.info("用户信息验证成功：[{}]", user.toString());// 检查商品合法性Stock stock = stockService.getStockById(sid);if (stock == null) {throw new Exception("商品不存在");}LOGGER.info("商品信息验证成功：[{}]", stock.toString());//乐观锁更新库存saleStockOptimistic(stock);LOGGER.info("乐观锁更新库存成功");//创建订单createOrderWithUserInfo(stock, userId);LOGGER.info("创建订单成功");return stock.getCount() - (stock.getSale()+1);
}

在上面的方法中，我们验证了时间，验证值匹配，用户信息，商品信息和库存。这样一个简单的带有验证的下单接口就完成了。接下里让我们来实际进行调用看一下情况。

接口测试

我们使用postman调用getVerifyHash获取请求抢购验证hash值：

我们去redis看一下这个值已经存在其中：

同时在控制台看出各种验证都是通过的：

有了这个验证值，接下来进行下单操作看是否可以下单成功：

可以看出我们去拿不验证通过并且成功下单。

单用户限制频率时间

假设我们做好了接口隐藏，但是像我上面说的，总有无聊的人会写一个复杂的脚本，先请求hash值，再立刻请求购买，如果你的app下单按钮做的很差，大家都要开抢后0.5秒才能请求成功，那可能会让脚本依然能够在大家前面抢购成功。这个时候我们需要在做一个额外的措施，来限制单个用户的抢购频率。实现方式其实也很简单：用redis给每个用户做访问统计。

我们使用外部缓存来解决问题，这样即便是分布式的秒杀系统，请求被随意分流的情况下，也能做到精准的控制每个用户的访问次数。这里选择redis。同样在Controller中添加要求验证的抢购接口 + 单用户限制访问频率的方法：

@RequestMapping(value = "/createOrderWithVerifiedUrlAndLimit", method = {RequestMethod.GET})
@ResponseBody
public String createOrderWithVerifiedUrlAndLimit(@RequestParam(value = "sid") Integer sid,@RequestParam(value = "userId") Integer userId,@RequestParam(value = "verifyHash") String verifyHash) {int stockLeft;try {int count = userService.addUserCount(userId);LOGGER.info("用户截至该次的访问次数为: [{}]", count);boolean isBanned = userService.getUserIsBanned(userId);if (isBanned) {return "购买失败，超过频率限制";}stockLeft = orderService.createVerifiedOrder(sid, userId, verifyHash);LOGGER.info("购买成功，剩余库存为: [{}]", stockLeft);} catch (Exception e) {LOGGER.error("购买失败：[{}]", e.getMessage());return e.getMessage();}return String.format("购买成功，剩余库存为：%d", stockLeft);
}

UserService中增加两个方法：addUserCount和getUserIsBanned。addUserCount进行每当访问订单接口，则增加一次访问次数，写入Redis；getUserIsBanned从Redis读出该用户的访问次数，超过一定次数则不让购买了，假设我们这里规定最多11次。代码如下：

   @Overridepublic int addUserCount(Integer userId) throws Exception {String limitKey = CacheKey.LIMIT_KEY.getKey() + "_" + userId;String limitNum = stringRedisTemplate.opsForValue().get(limitKey);int limit = -1;if (limitNum == null) {stringRedisTemplate.opsForValue().set(limitKey, "0", 3600, TimeUnit.SECONDS);} else {limit = Integer.parseInt(limitNum) + 1;stringRedisTemplate.opsForValue().set(limitKey, String.valueOf(limit), 3600, TimeUnit.SECONDS);}return limit;}@Overridepublic boolean getUserIsBanned(Integer userId) {String limitKey = CacheKey.LIMIT_KEY.getKey() + "_" + userId;String limitNum = stringRedisTemplate.opsForValue().get(limitKey);if (limitNum == null) {LOGGER.error("该用户没有访问申请验证值记录，疑似异常");return true;}return Integer.parseInt(limitNum) > ALLOW_COUNT;}

接下来还是实际进行操作，看一下最终的结果。我们依然使用Jmeter进行同一用户20次的访问量，看一下执行结果：

可以看到到第十一次的时候就不允许抢购了。所以我们实现了统一用户访问频率的拦截。

猜你感兴趣：
教你从0到1搭建秒杀系统-防超卖
教你从0到1搭建秒杀系统-限流
教你从0到1搭建秒杀系统-抢购接口隐藏与单用户限制频率
教你从0到1搭建秒杀系统-缓存与数据库双写一致
教你从0到1搭建秒杀系统-Canal快速入门（番外篇）
教你从0到1搭建秒杀系统-订单异步处理

更多文章请点击：更多…

参考文章：
https://cloud.tencent.com/developer/article/1488059
https://juejin.im/post/5dd09f5af265da0be72aacbd
https://zhenganwen.top/posts/30bb5ce6/
https://www.cnblogs.com/java-my-life/archive/2012/06/08/2538146.html

教你从0到1搭建秒杀系统-抢购接口隐藏与单用户限制频率相关推荐

教你从0到1搭建秒杀系统-订单异步处理
前面几篇我们从限流角度,缓存角度来优化了用户下单的速度,减少了服务器和数据库的压力.这些处理对于一个秒杀系统都是非常重要的,并且效果立竿见影,那还有什么操作也能有立竿见影的效果呢?答案是下单的异步处理 ...
教你从0到1搭建秒杀系统-Canal快速入门（番外篇）
Canal用途很广,并且上手非常简单,小伙伴们在平时完成公司的需求时,很有可能会用到.本篇介绍一下数据库中间件Canal的使用. 很多时候为了缩短调用延时,我们会对部分接口数据加入了缓存.一旦这些数据 ...
教你从0到1搭建秒杀系统-缓存与数据库双写一致
本文是秒杀系统的第四篇,我们来讨论秒杀系统中缓存热点数据的问题,进一步延伸到数据库和缓存的双写一致性问题. 在秒杀实际的业务中,一定有很多需要做缓存的场景,比如售卖的商品,包括名称,详情等.访问量很大 ...
教你从0到1搭建秒杀系统-限流
本文是秒杀系统的第二篇,主要讲解接口限流措施.接口限流其实定义也非常广,接口限流本身也是系统安全防护的一种措施,在面临高并发的请购请求时,我们如果不对接口进行限流,可能会对后台系统造成极大的压力,尤其 ...
教你从0到1搭建秒杀系统-防超卖
各位读者好,最近笔者学了很多东西,其实都想跟大家进行分享,奈何需要将所学习的知识整理出来需要耗费大量的时间,包括总结,或各种图形以及写代码示例,所以可能更新的速度会比较慢.但大家放心,只要有时间我就会 ...
【秒杀系统】零基础上手秒杀系统（三）：抢购接口隐藏 + 单用户限制频率
前言时光飞逝,两周过去了,是时候继续填坑了,不然又要被网友喷了. 本文是秒杀系统的第三篇,通过实际代码讲解,帮助你了解秒杀系统设计的关键点,上手实际项目. 本篇主要讲解秒杀系统中,关于抢购(下单)接 ...
如何从0到1搭建物联网系统？
如何从0到1搭建物联网系统? 2019年是一个好的开端,在互联网行业混迹3年,充分理解互联网行业关于用户思维.平台思维的诠释后,以及对于敏捷研发.协同工作等新思想新管理模式实践后,我准备回身物联网产业 ...
B2C电商项目（第十五天、秒杀后端、异步下单、防止恶意刷单、防止重复秒杀、下单接口隐藏、下单接口限流 )
秒杀后端学习内容 : 1)实现秒杀异步下单,掌握如何保证生产者&消费者消息不丢失 2)实现防止恶意刷单 3)实现防止相同商品重复秒杀 4)实现秒杀下单接口隐藏 5)实现下单接口限流一.秒杀 ...
手把手教你从0到1搭建vue3+ts+vite+element-plus简易后台管理系统
准备工作首先请确保你的node.js版本>=12.0.0 因为vite的兼容性,Vite 需要 Node.js 版本 >= 12.0.0. 如果你不知道你的node.js的版本是多少,请 ...

教你从0到1搭建秒杀系统-抢购接口隐藏与单用户限制频率