前言 

大家好，我是田螺。

星球粉絲分享了一道面試題：10萬QPS高并發(fā)請求，如何防止重復(fù)下單。本文田螺哥從面試的角度，跟大家一起探討一下，從前端到后端，全鏈路，一層層遞進(jìn)探討！

1. 前端攔截 

首先因為是10萬QPS的高并發(fā)請求，我們要保護(hù)好系統(tǒng)，那就是盡可能減少用戶無效請求。

1.1 按鈕置灰

很多用戶搶票、搶購、搶紅包等時候，為了提高搶中的概率，都是瘋狂點(diǎn)擊按鈕。會觸發(fā)多次請求，導(dǎo)致重復(fù)下單。

因此，在用戶點(diǎn)擊過搶購按鈕后，我們可以給按鈕置灰，不讓用戶重復(fù)點(diǎn)擊。

const submitButton = document.getElementById('submit-order');
submitButton.disabled = true;  // 禁用按鈕
// 提交訂單的異步操作
submitOrder().then(response => {
  submitButton.disabled = false;  // 請求完成后恢復(fù)按鈕
}).catch(error => {
  submitButton.disabled = false;  // 請求失敗也恢復(fù)按鈕
});

如果你的系統(tǒng)希望設(shè)計得友好一點(diǎn)，可以前端提示個文案，比如：已經(jīng)收到你的請求，請耐心等待搶購結(jié)果。

1.2 Token機(jī)制

• 前端加載頁面的時候，獲取一個全局唯一標(biāo)記的token，如UUID。
• 在表單提交時，用該Token來標(biāo)識該請求。每次請求都附帶該Token，后端驗證Token是否唯一。如果已提交過該Token的請求，則直接返回錯誤或無效響應(yīng)，防止重復(fù)提交。

2.后端設(shè)計 

2.1 NGINX 限流

請求從前端到后端，首先是先到nginx ，我們可以在nginx做一下限流。

因為有些用戶不懷好意，通過腳本繞過前端，瘋狂請求。這類用戶的IP和用戶ID，我們都可以做一下限流的限制的。

一個Nginx限流配置：

http {
    # 核心配置：IP+用戶ID雙因子限流 (按業(yè)務(wù)需求二選一)
    
    ## 選項1：基礎(chǔ)版（純IP限制）
    limit_req_zone $binary_remote_addr zone=order_base:10m rate=3r/m;  # 每IP每分鐘3次

    ## 選項2：增強(qiáng)版（IP+用戶ID，需前端傳遞UserID）
    limit_req_zone $binary_remote_addr$http_user_id zone=order_enhanced:20m rate=5r/m;

    server {
        listen 80;
        server_name tianluoboy.com;

        # 訂單提交接口
        location = /v1/order/create {
            # 啟用限流（示例用增強(qiáng)版）
            limit_req zone=order_enhanced burst=3 nodelay;  
            
            # 返回429時強(qiáng)制JSON響應(yīng)
            error_page 429 @toofast;
            location @toofast {
                default_type application/json;
                return 200 '{"code":429,"msg":"操作過于頻繁，請稍后再試"}';
            }

            # 反向代理到業(yè)務(wù)服務(wù)器
            proxy_pass http://order_backend;
        }

        # 其他接口不限流
        location / {
            proxy_pass http://default_backend;
        }
    }
}

2.2 網(wǎng)關(guān)（Spring Cloud Gateway）

網(wǎng)關(guān)層可以做的事情很多，比如

Token 校驗：在網(wǎng)關(guān)層攔截請求，驗證 Token 是否在 Redis 中存在.

// 偽代碼示例：網(wǎng)關(guān)過濾器校驗 Token
if (redis.get(token) != null) {
    return error("重復(fù)請求");
} else {
    redis.setex(token, 60, "1"); // Token 有效期 60 秒
    //請求到后臺
    passToBackend();
}

當(dāng)然，網(wǎng)關(guān)也可以做限流的：

• 令牌桶算法：通過Redis + Lua 實現(xiàn)集群級限流（如 redis-cell 模塊）。
• 用戶維度限流：基于用戶 ID或設(shè)備指紋限制并發(fā)請求數(shù)。

網(wǎng)關(guān)層可以做一下請求排隊：

• 對高并發(fā)請求放到消息隊列，削峰填谷（如 Kafka/RabbitMQ）

圖片

2.3 冪等設(shè)計

下單業(yè)務(wù)接口，我們一般要做冪等的。

一般用唯一索引做冪等設(shè)計。

唯一索引：比如使用用戶ID + 商品ID + 時間戳組合生成唯一訂單號。

一般的冪等處理就是這樣啦，如下：

圖片

2.4 分庫分表

分庫分表：按用戶 ID 分片，分散寫壓力，避免單表成為瓶頸。

當(dāng)業(yè)務(wù)量暴增的話，MySQL單機(jī)磁盤容量會撐爆。并且，我們知道數(shù)據(jù)庫連接數(shù)是有限的。在高并發(fā)的場景下，大量請求訪問數(shù)據(jù)庫，MySQL單機(jī)是扛不住的！高并發(fā)場景下，會出現(xiàn)too many connections報錯。

所以高并發(fā)的系統(tǒng)，需要考慮拆分為多個數(shù)據(jù)庫，來抗住高并發(fā)的毒打。而假如你的單表數(shù)據(jù)量非常大，存儲和查詢的性能就會遇到瓶頸了，如果你做了很多優(yōu)化之后還是無法提升效率的時候，就需要考慮做分表了。一般千萬級別數(shù)據(jù)量，就需要分表，每個表的數(shù)據(jù)量少一點(diǎn)，提升SQL查詢性能。

2.5 分布式鎖

既然是防止重復(fù)下單，一般都需要加Redis分布式鎖的。

// 偽代碼：Redisson 分布式鎖
RLock lock = redisson.getLock("order:lock:" + userId);
if (lock.tryLock(0, 30, TimeUnit.SECONDS)) {
    try {
        createOrder();
    } finally {
        lock.unlock();
    }
}

2.6 樂觀鎖兜底

如果分布式鎖失效了呢？怎么辦呢?

我們可以加數(shù)據(jù)庫樂觀鎖兜底。比如

• 在數(shù)據(jù)訂單表中添加 version 字段，每次更新都version+1，更新時校驗版本號
• 通過原子操作 UPDATE ... SET versinotallow=version+1 WHERE order_id=xx AND versinotallow=old_version實現(xiàn)

2.7 日志與監(jiān)控

要打印好日志，和做好監(jiān)控指標(biāo)，如果發(fā)現(xiàn)日志或者監(jiān)控異常，可以快速介入排查~

打印日志也有坑：

圖片

有需要的伙伴可以購買我的踩坑專欄哈：血與淚的教訓(xùn)，盤點(diǎn)我工作七年所踩的坑（更新到90篇啦~）

2.8 核對數(shù)據(jù)

我們要做好核對數(shù)據(jù)，比如做個定時任務(wù)，核對訂單數(shù)據(jù)和交易金額是否對得上，如果發(fā)現(xiàn)數(shù)據(jù)異常，就人工快速介入排查和修復(fù)。