零基礎上手秒殺系統：搶購接口隱藏 + 單用戶限制頻率

前言

時光飛逝，兩週過去了，是時候繼續填坑了，不然又要被網友噴了。

本文是秒殺系統的第三篇，通過實際代碼講解，幫助你瞭解秒殺系統設計的關鍵點，上手實際項目。

本篇主要講解秒殺系統中，關於搶購（下單）接口相關的單用戶防刷措施，主要說兩塊內容：

• 搶購接口隱藏
• 單用戶限制頻率（單位時間內限制訪問次數）

當然，這兩個措施放在任何系統中都有用，嚴格來說並不是秒殺系統獨特的設計，所以今天的內容也會比較的通用。

此外，我做了一張流程圖，描述了目前我們實現的秒殺接口下單流程：

前文回顧和文章規劃

• 零基礎上手秒殺系統（一）：防止超賣
• 零基礎上手秒殺系統（二）：令牌桶限流 + 再談超賣
• 零基礎上手秒殺系統（三）：搶購接口隱藏 + 單用戶限制頻率（本篇）
• 零基礎上手秒殺系統：使用Redis緩存熱點數據
• 零基礎上手秒殺系統：消息隊列異步處理訂單
• …

歡迎關注我的個人公眾號獲取最全的原創文章：後端技術漫談（二維碼見文章底部）

項目源碼在這裡

媽媽再也不用擔心只會看文章不會實現啦：

https://github.com/qqxx6661/miaosha

正文

秒殺系統介紹

可以翻閱該系列的第一篇文章，這裡不再回顧：

零基礎上手秒殺系統（一）：防止超賣

搶購接口隱藏

在前兩篇文章的介紹下，我們完成了防止超賣商品和搶購接口的限流，已經能夠防止大流量把我們的服務器直接搞炸，這篇文章中，我們要開始關心一些細節問題。

對於稍微懂點電腦的，又會動歪腦筋的人來說，點擊F12打開瀏覽器的控制檯，就能在點擊搶購按鈕後，獲取我們搶購接口的鏈接。（手機APP等其他客戶端可以抓包來拿到）

一旦壞蛋拿到了搶購的鏈接，只要稍微寫點爬蟲代碼，模擬一個搶購請求，就可以不通過點擊下單按鈕，直接在代碼中請求我們的接口，完成下單。所以就有了成千上萬的薅羊毛軍團，寫一些腳本搶購各種秒殺商品。

他們只需要在搶購時刻的000毫秒，開始不間斷髮起大量請求，覺得比大家在APP上點搶購按鈕要快，畢竟人的速度又極限，更別說APP說不定還要經過幾層前端驗證才會真正發出請求。

所以我們需要將搶購接口進行隱藏，搶購接口隱藏（接口加鹽）的具體做法

：

• 每次點擊秒殺按鈕，先從服務器獲取一個秒殺驗證值（接口內判斷是否到秒殺時間）。
• Redis以緩存用戶ID和商品ID為Key，秒殺地址為Value緩存驗證值
• 用戶請求秒殺商品的時候，要帶上秒殺驗證值進行校驗。

大家先停下來仔細想想，通過這樣的辦法，能夠防住通過腳本刷接口的人嗎？

能，也不能。

可以防住的是直接請求接口的人，但是隻要壞蛋們把腳本寫複雜一點，先去請求一個驗證值，再立刻請求搶購，也是能夠搶購成功的。

不過壞蛋們請求驗證值接口，也需要在搶購時間開始後，才能請求接口拿到驗證值，然後才能申請搶購接口。理論上來說在訪問接口的時間上受到了限制，並且我們還能通過在驗證值接口增加更復雜的邏輯，讓獲取驗證值的接口並不快速返回驗證值，進一步拉平普通用戶和壞蛋們的下單時刻

。所以接口加鹽還是有用的！

下面我們就實現一種簡單的加鹽接口代碼，拋磚引玉。

代碼邏輯實現

代碼還是使用之前的項目，我們在其上面增加兩個接口：

• 獲取驗證值接口
• 攜帶驗證值下單接口

由於之前我們只有兩個表，一個stock表放庫存商品，一個stockOrder訂單表，放訂購成功的記錄。但是這次涉及到了用戶，所以我們新增用戶表，並且添加一個用戶張三。並且在訂單表中，不僅要記錄商品id，同時要寫入用戶id。

整個SQL結構如下，講究一個簡潔，暫時不加入別的多餘字段：

<code>-- ----------------------------
-- 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', '張三');/<code>

SQL文件在開源代碼裡也放了，不用擔心。

獲取驗證值接口

該接口要求傳用戶id和商品id，返回驗證值，並且該驗證值

Controller中添加方法：

<code>/**
 * 獲取驗證值
 * @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);
}/<code>

UserService中添加方法：

<code>@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;
}/<code>

一個Cache常量枚舉類CacheKey：

<code>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;
    }
}/<code>

代碼解釋：

可以看到在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中添加方法：

<code>/**
 * 要求驗證的搶購接口
 * @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);
}/<code>

OrderService中添加方法：

<code>@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);
}/<code>

代碼解釋：

可以看到service中，我們需要驗證了：

• 商品信息
• 用戶信息
• 時間
• 庫存

如此，我們便完成了一個擁有驗證的下單接口。

試驗一下接口

我們先讓用戶1，法外狂徒張三登場，發起請求：

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

得到結果:

控制檯輸出：

別急著下單，我們看一下redis裡有沒有存儲好key：

木偶問題，接下來，張三可以去請求下單了！

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

得到輸出結果：

法外狂徒張三搶購成功了！

單用戶限制頻率

假設我們做好了接口隱藏，但是像我上面說的，總有無聊的人會寫一個複雜的腳本，先請求hash值，再立刻請求購買，如果你的app下單按鈕做的很差，大家都要開搶後0.5秒才能請求成功，那可能會讓腳本依然能夠在大家前面搶購成功。

我們需要在做一個額外的措施，來限制單個用戶的搶購頻率。

其實很簡單的就能想到用redis給每個用戶做訪問統計，甚至是帶上商品id，對單個商品做訪問統計，這都是可行的。

我們先實現一個對用戶的訪問頻率限制，我們在用戶申請下單時，檢查用戶的訪問次數，超過訪問次數，則不讓他下單！

使用Redis/Memcached

我們使用外部緩存來解決問題，這樣即便是分佈式的秒殺系統，請求被隨意分流的情況下，也能做到精準的控制每個用戶的訪問次數。

Controller中添加方法：

<code>/**
 * 要求驗證的搶購接口 + 單用戶限制訪問頻率
 * @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);
}/<code>

UserService中增加兩個方法：

• addUserCount：每當訪問訂單接口，則增加一次訪問次數，寫入Redis
• getUserIsBanned：從Redis讀出該用戶的訪問次數，超過10次則不讓購買了！不能讓張三做法外狂徒。

<code>@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;
    }/<code>

試一試接口

使用前文用的JMeter做併發訪問接口30次，可以看到下單了10次後，不讓再購買了：

大功告成了。

能否不用Redis/Memcached實現用戶訪問頻率統計

且慢，如果你說你不願意用redis，有什麼辦法能夠實現訪問頻率統計嗎，有呀，如果你放棄分佈式的部署服務，那麼你可以在內存中存儲訪問次數，比如：

• Google Guava的內存緩存
• 狀態模式

不知道大家的設計模式複習的怎麼樣了，如果沒有複習到狀態模式，可以先去看看狀態模式的定義。狀態模式很適合實現這種訪問次數限制場景。

我的博客和公眾號（後端技術漫談）裡，寫了個《設計模式自習室》系列，詳細介紹了每種設計模式，大家有興趣可可以看看。【設計模式自習室】開篇：為什麼要有設計模式？

這裡我就不實現了，畢竟咱們還是分佈式秒殺服務為主，不過引用一個博客的例子，大家感受下狀態模式的實際應用：

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

考慮一個在線投票系統的應用，要實現控制同一個用戶只能投一票，如果一個用戶反覆投票，而且投票次數超過5次，則判定為惡意刷票，要取消該用戶投票的資格，當然同時也要取消他所投的票；如果一個用戶的投票次數超過8次，將進入黑名單，禁止再登錄和使用系統。

<code>public class VoteManager {
    //持有狀體處理對象
    private VoteState state = null;
    //記錄用戶投票的結果，Map對應Map
    private Map mapVote = new HashMap();
    //記錄用戶投票次數，Map對應Map
    private Map mapVoteCount = new HashMap();
    /**
     * 獲取用戶投票結果的Map
     */
    public Map 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 && oldVoteCount <8){
            state = new SpiteVoteState();
        }
        else if(oldVoteCount > 8){
            state = new BlackVoteState();
        }
        //然後轉調狀態對象來進行相應的操作
        state.vote(user, voteItem, this);
    }
}/<code>

<code>public class Client {

    public static void main(String[] args) {

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

}/<code>

結果：

總結

本項目的代碼開源在了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
• CSDN：@Rude3knife
• 知乎：@後端技術漫談
• 簡書：@蠻三刀把刀
• 掘金：@蠻三刀把刀

原創博客主要內容

• 後端開發技術
• Java面試知識點
• 設計模式/數據結構
• LeetCode/劍指offer 算法題解析
• SpringBoot/SpringCloud入門實戰系列
• 數據分析/數據爬蟲
• 逸聞趣事/好書分享/個人生活

個人公眾號：後端技術漫談

公眾號：後端技術漫談.jpg

如果文章對你有幫助，不妨收藏，轉發，在看起來~