在前两篇文章的介绍下,我们完成了防止超卖商品和抢购接口的限流,已经能够防止大流量把我们的服务器直接搞炸,这篇文章中,我们要开始关心一些细节问题。对于稍微懂点电脑的,点击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());
// 生成hash
String verify = SALT + sid + userId;
String verifyHash = DigestUtils.md5DigestAsHex(verify.getBytes());
// 将hash和用户商品信息存入redis
String 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次。代码如下:
@Override
public 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;
}
@Override
public 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