10萬QPS高并發請求，如何防止重復下單
前言
大家好，我是田螺。
星球粉絲分享了一道面試題：10萬QPS高并發請求，如何防止重復下單。本文田螺哥從面試的角度，跟大家一起探討一下，從前端到后端，全鏈路，一層層遞進探討！
1. 前端攔截
首先因為是10萬QPS的高并發請求，我們要保護好系統，那就是盡可能減少用戶無效請求。
1.1 按鈕置灰
很多用戶搶票、搶購、搶紅包等時候，為了提高搶中的概率，都是瘋狂點擊按鈕。會觸發多次請求，導致重復下單。
因此，在用戶點擊過搶購按鈕后，我們可以給按鈕置灰，不讓用戶重復點擊。
const submitButton = document.getElementById('submit-order');
submitButton.disabled = true; // 禁用按鈕
// 提交訂單的異步操作
submitOrder().then(response => {
submitButton.disabled = false; // 請求完成后恢復按鈕
}).catch(error => {
submitButton.disabled = false; // 請求失敗也恢復按鈕
});如果你的系統希望設計得友好一點，可以前端提示個文案，比如：已經收到你的請求，請耐心等待搶購結果。
1.2 Token機制
- 前端加載頁面的時候，獲取一個全局唯一標記的token，如UUID。
- 在表單提交時，用該Token來標識該請求。每次請求都附帶該Token，后端驗證Token是否唯一。如果已提交過該Token的請求，則直接返回錯誤或無效響應，防止重復提交。
2.后端設計
2.1 NGINX 限流
請求從前端到后端，首先是先到nginx ，我們可以在nginx做一下限流。
因為有些用戶不懷好意，通過腳本繞過前端，瘋狂請求。這類用戶的IP和用戶ID，我們都可以做一下限流的限制的。
一個Nginx限流配置：
http {
# 核心配置：IP+用戶ID雙因子限流 (按業務需求二選一)
## 選項1：基礎版（純IP限制）
limit_req_zone $binary_remote_addr zone=order_base:10m rate=3r/m; # 每IP每分鐘3次
## 選項2：增強版（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 {
# 啟用限流（示例用增強版）
limit_req zone=order_enhanced burst=3 nodelay;
# 返回429時強制JSON響應
error_page 429 @toofast;
location @toofast {
default_type application/json;
return 200 '{"code":429,"msg":"操作過于頻繁，請稍后再試"}';
}
# 反向代理到業務服務器
proxy_pass http://order_backend;
}
# 其他接口不限流
location / {
proxy_pass http://default_backend;
}
}
}2.2 網關（Spring Cloud Gateway）
網關層可以做的事情很多，比如
Token 校驗：在網關層攔截請求，驗證 Token 是否在 Redis 中存在.
// 偽代碼示例：網關過濾器校驗 Token
if (redis.get(token) != null) {
return error("重復請求");
} else {
redis.setex(token, 60, "1"); // Token 有效期 60 秒
//請求到后臺
passToBackend();
}當然，網關也可以做限流的：
- 令牌桶算法：通過Redis + Lua 實現集群級限流（如 redis-cell 模塊）。
- 用戶維度限流：基于用戶 ID或設備指紋限制并發請求數。
網關層可以做一下請求排隊：
- 對高并發請求放到消息隊列，削峰填谷（如 Kafka/RabbitMQ）
圖片
2.3 冪等設計
下單業務接口，我們一般要做冪等的。
一般用唯一索引做冪等設計。
唯一索引：比如使用用戶ID + 商品ID + 時間戳組合生成唯一訂單號。
一般的冪等處理就是這樣啦，如下：
圖片
2.4 分庫分表
分庫分表：按用戶 ID 分片，分散寫壓力，避免單表成為瓶頸。
當業務量暴增的話，MySQL單機磁盤容量會撐爆。并且，我們知道數據庫連接數是有限的。在高并發的場景下，大量請求訪問數據庫，MySQL單機是扛不住的！高并發場景下，會出現too many connections報錯。
所以高并發的系統，需要考慮拆分為多個數據庫，來抗住高并發的毒打。而假如你的單表數據量非常大，存儲和查詢的性能就會遇到瓶頸了，如果你做了很多優化之后還是無法提升效率的時候，就需要考慮做分表了。一般千萬級別數據量，就需要分表，每個表的數據量少一點，提升SQL查詢性能。
2.5 分布式鎖
既然是防止重復下單，一般都需要加Redis分布式鎖的。
// 偽代碼：Redisson 分布式鎖
RLock lock = redisson.getLock("order:lock:" + userId);
if (lock.tryLock(0, 30, TimeUnit.SECONDS)) {
try {
createOrder();
} finally {
lock.unlock();
}
}2.6 樂觀鎖兜底
如果分布式鎖失效了呢？怎么辦呢?
我們可以加數據庫樂觀鎖兜底。比如
- 在數據訂單表中添加 version 字段，每次更新都version+1，更新時校驗版本號
- 通過原子操作 UPDATE ... SET versinotallow=version+1 WHERE order_id=xx AND versinotallow=old_version實現
2.7 日志與監控
要打印好日志，和做好監控指標，如果發現日志或者監控異常，可以快速介入排查~
打印日志也有坑：
圖片
有需要的伙伴可以購買我的踩坑專欄哈：血與淚的教訓，盤點我工作七年所踩的坑（更新到90篇啦~）
2.8 核對數據
我們要做好核對數據，比如做個定時任務，核對訂單數據和交易金額是否對得上，如果發現數據異常，就人工快速介入排查和修復。
