【秒杀系统】零基础上手秒杀系统（三）：抢购接口隐藏 + 单用户限制频率

时间  2020-12-07
标签 html 前端 java git 程序员 github 面试 redis 算法 后端 栏目 HTML 繁體版
原文   原文链接

【秒杀系统】零基础上手秒杀系统（三）：抢购接口隐藏 + 单用户限制频率

前言

时光飞逝，两周过去了，是时候继续填坑了，否则又要被网友喷了。html

本文是秒杀系统的第三篇，经过实际代码讲解，帮助你了解秒杀系统设计的关键点，上手实际项目。前端

本篇主要讲解秒杀系统中，关于抢购（下单）接口相关的单用户防刷措施，主要说两块内容：java

  • 抢购接口隐藏
  • 单用户限制频率（单位时间内限制访问次数）

固然，这两个措施放在任何系统中都有用，严格来讲并非秒杀系统独特的设计，因此今天的内容也会比较的通用。git

此外，我作了一张流程图，描述了目前咱们实现的秒杀接口下单流程：
【秒杀系统】零基础上手秒杀系统（三）：抢购接口隐藏 + 单用户限制频率程序员

前文回顾和文章规划

  • 零基础上手秒杀系统（一）：防止超卖
  • 零基础上手秒杀系统（二）：令牌桶限流 + 再谈超卖
  • 零基础上手秒杀系统（三）：抢购接口隐藏 + 单用户限制频率（本篇）
  • 零基础上手秒杀系统：使用Redis缓存热点数据
  • 零基础上手秒杀系统：消息队列异步处理订单
  • …

欢迎关注个人我的公众号获取最全的原创文章：后端技术漫谈（二维码见文章底部）github

项目源码在这里

妈妈不再用担忧只会看文章不会实现啦：面试

https://github.com/qqxx6661/miaosharedis

抢购接口隐藏

在前两篇文章的介绍下，咱们完成了防止超卖商品和抢购接口的限流，已经可以防止大流量把咱们的服务器直接搞炸，这篇文章中，咱们要开始关心一些细节问题。算法

对于稍微懂点电脑的，又会动歪脑筋的人来讲，点击F12打开浏览器的控制台，就能在点击抢购按钮后，获取咱们抢购接口的连接。（手机APP等其余客户端能够抓包来拿到）后端

一旦坏蛋拿到了抢购的连接，只要稍微写点爬虫代码，模拟一个抢购请求，就能够不经过点击下单按钮，直接在代码中请求咱们的接口，完成下单。因此就有了成千上万的薅羊毛军团，写一些脚本抢购各类秒杀商品。

他们只须要在抢购时刻的000毫秒，开始不间断发起大量请求，以为比你们在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', '张三');

SQL文件在开源代码里也放了，不用担忧。

获取验证值接口

该接口要求传用户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;
}

一个Cache常量枚举类CacheKey：

package cn.monitor4all.miaoshadao.utils;

public enum CacheKey {
    HASH_KEY("miaosha_hash"),
    LIMIT_KEY("miaosha_limit");

    private String key;

    private CacheKey(String key) {
        this.key = key;
    }
    public String getKey() {
        return key;
    }
}

代码解释：

能够看到在Service中，咱们拿到用户id和商品id后，会检查商品和用户信息是否在表中存在，而且会验证如今的时间（我这里为了简化，只是写了一行LOGGER，你们能够根据需求自行实现）。在这样的条件过滤下，才会给出hash值。而且将Hash值写入了Redis中，缓存3600秒（1小时），若是用户拿到这个hash值一小时内没下单，则须要从新获取hash值。

下面又到了动小脑筋的时间了，想一下，这个hash值，若是每次都按照商品+用户的信息来md5，是否是不太安全呢。毕竟用户id并不必定是用户不知道的（就好比我这种用自增id存储的，确定不安全），而商品id，万一也泄露了出去，那么坏蛋们若是再知到咱们是简单的md5，那直接就把hash算出来了！

在代码里，我给hash值加了个前缀，也就是一个salt（盐），至关于给这个固定的字符串撒了一把盐，这个盐是HASH_KEY("miaosha_hash")，写死在了代码里。这样黑产只要不猜到这个盐，就没办法算出来hash值。

这也只是一种例子，实际中，你能够把盐放在其余地方， 而且不断变化，或者结合时间戳，这样就算本身的程序员也无法知道hash值的本来字符串是什么了。

携带验证值下单接口

用户在前台拿到了验证值后，点击下单按钮，前端携带着特征值，便可进行下单操做。

Controller中添加方法：

/**
 * 要求验证的抢购接口
 * @param sid
 * @return
 */
@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);
}

代码解释：

能够看到service中，咱们须要验证了：

  • 商品信息
  • 用户信息
  • 时间
  • 库存

如此，咱们便完成了一个拥有验证的下单接口。

试验一下接口

咱们先让用户1，法外狂徒张三登场，发起请求：

http://localhost:8080/getVerifyHash?sid=1&userId=1

获得结果:

【秒杀系统】零基础上手秒杀系统（三）：抢购接口隐藏 + 单用户限制频率
控制台输出：
【秒杀系统】零基础上手秒杀系统（三）：抢购接口隐藏 + 单用户限制频率

别急着下单，咱们看一下redis里有没有存储好key：
【秒杀系统】零基础上手秒杀系统（三）：抢购接口隐藏 + 单用户限制频率

木偶问题，接下来，张三能够去请求下单了！

http://localhost:8080/createOrderWithVerifiedUrl?sid=1&userId=1&verifyHash=d4ff4c458da98f69b880dd79c8a30bcf

获得输出结果：
【秒杀系统】零基础上手秒杀系统（三）：抢购接口隐藏 + 单用户限制频率

法外狂徒张三抢购成功了！

单用户限制频率

假设咱们作好了接口隐藏，可是像我上面说的，总有无聊的人会写一个复杂的脚本，先请求hash值，再马上请求购买，若是你的app下单按钮作的不好，你们都要开抢后0.5秒才能请求成功，那可能会让脚本依然可以在你们前面抢购成功。

咱们须要在作一个额外的措施，来限制单个用户的抢购频率。

其实很简单的就能想到用redis给每一个用户作访问统计，甚至是带上商品id，对单个商品作访问统计，这都是可行的。

咱们先实现一个对用户的访问频率限制，咱们在用户申请下单时，检查用户的访问次数，超过访问次数，则不让他下单！

使用Redis/Memcached

咱们使用外部缓存来解决问题，这样即使是分布式的秒杀系统，请求被随意分流的状况下，也能作到精准的控制每一个用户的访问次数。

Controller中添加方法：

/**
 * 要求验证的抢购接口 + 单用户限制访问频率
 * @param sid
 * @return
 */
@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：每当访问订单接口，则增长一次访问次数，写入Redis
  • getUserIsBanned：从Redis读出该用户的访问次数，超过10次则不让购买了！不能让张三作法外狂徒。
@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作并发访问接口30次，能够看到下单了10次后，不让再购买了：
【秒杀系统】零基础上手秒杀系统（三）：抢购接口隐藏 + 单用户限制频率
【秒杀系统】零基础上手秒杀系统（三）：抢购接口隐藏 + 单用户限制频率
【秒杀系统】零基础上手秒杀系统（三）：抢购接口隐藏 + 单用户限制频率

大功告成了。

可否不用Redis/Memcached实现用户访问频率统计

且慢，若是你说你不肯意用redis，有什么办法可以实现访问频率统计吗，有呀，若是你放弃分布式的部署服务，那么你能够在内存中存储访问次数，好比：

  • Google Guava的内存缓存
  • 状态模式

不知道你们的设计模式复习的怎么样了，若是没有复习到状态模式，能够先去看看状态模式的定义。状态模式很适合实现这种访问次数限制场景。

个人博客和公众号（后端技术漫谈）里，写了个《设计模式自习室》系列，详细介绍了每种设计模式，你们有兴趣可能够看看。【设计模式自习室】开篇：为何要有设计模式？

这里我就不实现了，毕竟我们仍是分布式秒杀服务为主，不过引用一个博客的例子，你们感觉下状态模式的实际应用：

https://www.cnblogs.com/java-my-life/archive/2012/06/08/2538146.html

考虑一个在线投票系统的应用，要实现控制同一个用户只能投一票，若是一个用户反复投票，并且投票次数超过5次，则断定为恶意刷票，要取消该用户投票的资格，固然同时也要取消他所投的票；若是一个用户的投票次数超过8次，将进入黑名单，禁止再登陆和使用系统。

public class VoteManager {
    //持有状体处理对象
    private VoteState state = null;
    //记录用户投票的结果，Map<String,String>对应Map<用户名称，投票的选项>
    private Map<String,String> mapVote = new HashMap<String,String>();
    //记录用户投票次数，Map<String,Integer>对应Map<用户名称，投票的次数>
    private Map<String,Integer> mapVoteCount = new HashMap<String,Integer>();
    /**
     * 获取用户投票结果的Map
     */
    public Map<String, String> getMapVote() {
        return mapVote;
    }
    /**
     * 投票
     * @param user    投票人
     * @param voteItem    投票的选项
     */
    public void vote(String user,String voteItem){
        //1.为该用户增长投票次数
        //从记录中取出该用户已有的投票次数
        Integer oldVoteCount = mapVoteCount.get(user);
        if(oldVoteCount == null){
            oldVoteCount = 0;
        }
        oldVoteCount += 1;
        mapVoteCount.put(user, oldVoteCount);
        //2.判断该用户的投票类型，就至关于判断对应的状态
        //究竟是正常投票、重复投票、恶意投票仍是上黑名单的状态
        if(oldVoteCount == 1){
            state = new NormalVoteState();
        }
        else if(oldVoteCount > 1 && oldVoteCount < 5){
            state = new RepeatVoteState();
        }
        else if(oldVoteCount >= 5 && oldVoteCount <8){
            state = new SpiteVoteState();
        }
        else if(oldVoteCount > 8){
            state = new BlackVoteState();
        }
        //而后转调状态对象来进行相应的操做
        state.vote(user, voteItem, this);
    }
}
public class Client {

    public static void main(String[] args) {

        VoteManager vm = new VoteManager();
        for(int i=0;i<9;i++){
            vm.vote("u1","A");
        }
    }

}

结果：

【秒杀系统】零基础上手秒杀系统（三）：抢购接口隐藏 + 单用户限制频率

总结

本项目的代码开源在了Github，你们随意使用：

https://github.com/qqxx6661/miaosha

最后，感谢你们的喜好。

但愿你们多多支持个人公主号：后端技术漫谈。

参考

关注我

我是一名后端开发工程师。

主要关注后端开发，数据安全，物联网，边缘计算方向，欢迎交流。

各大平台均可以找到我

  • 微信公众号：后端技术漫谈
  • Github：@qqxx6661
  • CSDN：@Rude3knife
  • 知乎：@后端技术漫谈
  • 简书：@蛮三刀把刀
  • 掘金：@蛮三刀把刀

原创博客主要内容

  • 后端开发技术
  • Java面试知识点
  • 设计模式/数据结构
  • LeetCode/剑指offer 算法题解析
  • SpringBoot/SpringCloud入门实战系列
  • 数据分析/数据爬虫
  • 逸闻趣事/好书分享/我的生活

    我的公众号：后端技术漫谈

    【秒杀系统】零基础上手秒杀系统（三）：抢购接口隐藏 + 单用户限制频率
    公众号：后端技术漫谈.jpg

若是文章对你有帮助，不妨收藏，转发，在看起来~

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程