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

灰太狼 2023-05-28 05:25 64阅读 0赞

![format_png][]

# 前言 #

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

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

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

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

当然，这两个措施放在任何系统中都有用，严格来说并不是秒杀系统独特的设计，所以今天的内容也会比较的通用。

此外，我做了一张流程图，描述了目前我们实现的秒杀接口下单流程：

![format_png 1][]

## 前文回顾和文章规划 ##

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

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

## 项目源码在这里 ##

妈妈再也不用担心只会看文章不会实现啦：

https://github.com/qqxx6661/miaosha

# 正文 #

## 秒杀系统介绍 ##

可以翻阅该系列的第一篇文章，这里不再回顾：

[零基础上手秒杀系统（一）：防止超卖][Link 3]

## 抢购接口隐藏 ##

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

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

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

他们只需要在抢购时刻的000毫秒，开始不间断发起大量请求，觉得比大家在APP上点抢购按钮要快，毕竟人的速度又极限，更别说APP说不定还要经过几层前端验证才会真正发出请求。

所以我们需要将抢购接口进行隐藏，**抢购接口隐藏（接口加盐）的具体做法**：

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

**大家先停下来仔细想想，通过这样的办法，能够防住通过脚本刷接口的人吗？**

**能，也不能。**

**可以防住的是直接请求接口的人，但是只要坏蛋们把脚本写复杂一点，先去请求一个验证值，再立刻请求抢购，也是能够抢购成功的。**

不过坏蛋们请求验证值接口，**也需要在抢购时间开始后**，才能请求接口拿到验证值，然后才能申请抢购接口。**理论上来说在访问接口的时间上受到了限制，并且我们还能通过在验证值接口增加更复杂的逻辑，让获取验证值的接口并不快速返回验证值，进一步拉平普通用户和坏蛋们的下单时刻**。所以接口加盐还是有用的！

下面我们就实现一种简单的加盐接口代码，抛砖引玉。

### 代码逻辑实现 ###

代码还是使用之前的项目，我们在其上面增加两个接口：

*  获取验证值接口
 *  携带验证值下单接口

由于之前我们只有两个表，一个stock表放库存商品，一个stockOrder订单表，放订购成功的记录。但是这次涉及到了用户，所以我们新增用户表，并且添加一个用户张三。并且在订单表中，不仅要记录商品id，同时要写入用户id。

整个SQL结构如下，讲究一个简洁，暂时不加入别的多余字段：

![format_png 2][]

-- ----------------------------
    -- 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

得到结果:

![format_png 3][]

控制台输出：

![format_png 4][]

别急着下单，我们看一下redis里有没有存储好key：

![format_png 5][]

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

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

得到输出结果：

![format_png 6][]

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

## 单用户限制频率 ##

假设我们做好了接口隐藏，但是像我上面说的，总有无聊的人会写一个复杂的脚本，先请求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次后，不让再购买了：

![format_png 7][]

![format_png 8][]

![format_png 9][]

大功告成了。

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

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

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

不知道大家的设计模式复习的怎么样了，如果没有复习到状态模式，可以先去看看状态模式的定义。状态模式很适合实现这种访问次数限制场景。

> 我的博客和公众号（后端技术漫谈）里，写了个《设计模式自习室》系列，详细介绍了每种设计模式，大家有兴趣可可以看看。[【设计模式自习室】开篇：为什么要有设计模式？][Link 4]

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

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");
            }
        }
    
    }

结果：

![format_png 10][]

# 总结 #

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

https://github.com/qqxx6661/miaosha

最后，感谢大家的喜爱。

希望大家多多支持我的公主号：后端技术漫谈。

# 参考 #

*  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

# 关注我 #

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

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

### 各大平台都可以找到我 ###

*  **微信公众号：后端技术漫谈**
 *  Github：[@qqxx6661][qqxx6661]
 *  CSDN：[@Rude3knife][Rude3knife]
 *  知乎：[@后端技术漫谈][Link 5]
 *  简书：[@蛮三刀把刀][Link 6]
 *  掘金：[@蛮三刀把刀][Link 7]

### 原创博客主要内容 ###

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

### 个人公众号：后端技术漫谈 ###

![公众号：后端技术漫谈.jpg][.jpg]

**如果文章对你有帮助，不妨收藏，转发，在看起来~**

[format_png]: /images/20230528/2eb2e5c268a44c708d756f1b1e3087db.png
[format_png 1]: /images/20230528/6ecc5a43457a428ebce76c081a7bb72b.png
[Link 1]: https://mp.weixin.qq.com/s?__biz=MzU1NTA0NTEwMg==&mid=2247484174&idx=1&sn=235af7ead49a7d33e7fab52e05d5021f&lang=zh_CN#rd
[Link 2]: https://mp.weixin.qq.com/s?__biz=MzU1NTA0NTEwMg==&mid=2247484178&idx=1&sn=f4d8072b5408b08f983cae26a6ce1cf5&lang=zh_CN#rd
[Link 3]: https://blog.csdn.net/qqxx6661/article/details/104720424
[format_png 2]: /images/20230528/60e74d0a817549449fd57f8e6995e50c.png
[format_png 3]: /images/20230528/306f97b36ceb49cc8c1d06e8a9cc0586.png
[format_png 4]: /images/20230528/00c533188d9742e69efc487c48a45251.png
[format_png 5]: /images/20230528/b6c3de8daa944688a1df498a55e9ac4d.png
[format_png 6]: /images/20230528/fd015d36f72841fd92b77bb895498216.png
[format_png 7]: /images/20230528/04db89a082c448ee80281d4ef81d9c48.png
[format_png 8]: /images/20230528/5d38295943d64535bfdf2aa5236b18eb.png
[format_png 9]: /images/20230528/5e1329f6c1104ca9aab2fb72ae0721ba.png
[Link 4]: https://mp.weixin.qq.com/s?__biz=MzU1NTA0NTEwMg==&mid=2247484082&idx=1&sn=8bffddbcb1484d3e9a09a7ca0e730f3b&chksm=fbdb1b33ccac9225d62df700df66a5d1d34e414071cb37a16753ffd09a763ff0e112a036320f&token=471477329&lang=zh_CN#rd
[format_png 10]: /images/20230528/74518304490a4f819d3a886bb0ab57d8.png
[qqxx6661]: https://github.com/qqxx6661
[Rude3knife]: http://blog.csdn.net/qqxx6661
[Link 5]: https://www.zhihu.com/people/yang-zhen-dong-1/
[Link 6]: https://www.jianshu.com/u/b5f225ca2376
[Link 7]: https://juejin.im/user/5b48015ce51d45191462ba55
[.jpg]: /images/20230528/6dfb1970729242f9a124d4f36b546aec.png