簡介一套基于Spring Boot 2.x的秒殺系統(tǒng)教學(xué)項目面向想要了解高并發(fā)搶購場景的Java開發(fā)者重點演示令牌桶限流、緩存預(yù)熱、分布式架構(gòu)、消息隊列、驗證碼防刷等關(guān)鍵技術(shù)點的落地方式。壓縮包共包含66個文件以23個Java源碼文件為核心另有SQL腳本用于初始化庫表與測試數(shù)據(jù)前端頁面HTML/CSS/JS輔助展示交互效果還有Maven配置、啟動腳本及README說明整體大小僅2.34MB結(jié)構(gòu)清晰便于導(dǎo)入開發(fā)環(huán)境后逐模塊閱讀。已有162人學(xué)習(xí)過該資源適合作為并發(fā)編程的實戰(zhàn)入門參考。通過該工程可以學(xué)習(xí)到一個完整秒殺系統(tǒng)的數(shù)據(jù)模型與目錄組織方式觀察商品庫存如何通過緩存和數(shù)據(jù)庫優(yōu)化應(yīng)對壓力同時借助附帶的頁面截圖和運行演示能夠更直觀地理解請求排隊、異步處理以及驗證碼校驗在項目中的真實用法涵蓋從架構(gòu)設(shè)計到代碼實現(xiàn)的完整思路無論是個人練手還是課程設(shè)計都能在此基礎(chǔ)上快速擴展。1. 秒殺系統(tǒng)為什么難別把高并發(fā)當(dāng)作“多線程加速”“高并發(fā)秒殺系統(tǒng)”這個詞在 Java 后端幾乎成了判斷一個人有沒有真正處理過流量沖擊的試金石。功能上無非是限時賣固定數(shù)量的商品可當(dāng)幾萬人同時點“立即搶購”幾萬個請求瞬間打進服務(wù)時常規(guī)的增刪改查思路就全崩了最先告警的不是數(shù)據(jù)庫而是 Tomcat 線程池、數(shù)據(jù)庫連接池、Redis 連接池最后數(shù)據(jù)庫被一大堆等待中的 SQL 拖垮庫存超賣、重復(fù)下單、頁面 5xx 一起冒出來。這篇文章想解決的不是“把秒殺跑通”而是“把秒殺跑穩(wěn)”。你會看到 Redis 預(yù)扣減庫存怎么擋住超賣、唯一索引怎么兜底重復(fù)下單、異步落庫怎么讓接口快速響應(yīng)以及壓測時 Nginx 和 Tomcat 上有哪些最容易被新手忽略的默認(rèn)參數(shù)。整套鏈路用 Spring Boot Redis MySQL 就能復(fù)現(xiàn)適合準(zhǔn)備 Java 面試的開發(fā)者也適合想在活動前把庫存系統(tǒng)補齊的后端。所謂“簡單實現(xiàn)”指的是不引入復(fù)雜中間件也能扛住相當(dāng)大的流量不是把庫存扣成負(fù)數(shù)的那種糙快猛。2. 系統(tǒng)設(shè)計先行先把超賣、重復(fù)下單和請求放大三個問題拆開2.1 三個并發(fā)難題超賣、重復(fù)下單、請求放大分別是怎么發(fā)生的秒殺系統(tǒng)第一次裸跑最常見的現(xiàn)象是庫存只有 100 件數(shù)據(jù)庫里卻生成了 300 多條訂單。對賬時發(fā)現(xiàn)不僅超賣還有大量重復(fù)訂單。這背后其實是三個獨立的問題混在一起排查會非常痛苦。超賣的直接原因是“檢查庫存”和“扣減庫存”不是原子操作。典型錯誤寫法是先SELECT stock判斷大于 0再執(zhí)行UPDATE。高并發(fā)下 100 個請求可能同時讀到“還有 1 件庫存”的快照于是都拿到了下單權(quán)限庫存最終變成負(fù)數(shù)。這里不是靠增加重試或加鎖就能解決的——如果鎖粒度不對要么排隊排到超時要么鎖競爭把數(shù)據(jù)庫拖垮。重復(fù)下單是接口冪等做得不夠。用戶手速快、雙擊按鈕、前端因請求超時自動重試、瀏覽器后退再提交同一秒能發(fā)出多次下單請求。如果訂單表沒有唯一約束、服務(wù)層沒做去重同一用戶就會在同一商品下生成多張訂單。你看著是用戶自己的操作問題實際是接口沒防御。請求放大則是量級問題。秒殺當(dāng)天的流量可能是日常的幾十倍假如所有請求都默認(rèn)打到 MySQL即使總數(shù)據(jù)量不大幾千條 SQL 同時排隊也會把連接池瞬間吃光。更麻煩的是 MySQL 連接一旦耗盡普通查詢跟著一起超時系統(tǒng)就不是“變慢”而是“雪崩”。這三個問題不能各自為戰(zhàn)必須在分層設(shè)計里一起解決讓無效流量在越靠前的位置被攔掉才是高并發(fā)系統(tǒng)的核心思路。2.2 分層架構(gòu)接入層、服務(wù)層、存儲層各自該守什么我一般把秒殺系統(tǒng)拆成三層來看。接入層用 Nginx 做靜態(tài)資源分離、連接復(fù)用和粗粒度限流服務(wù)層用 Spring Boot 做活動校驗、用戶去重和 Redis 預(yù)扣減存儲層里 Redis 保存熱點庫存MySQL 保存最終訂單和可信庫存。三層各自守住一條底線才不會互相拖累。分層核心職責(zé)關(guān)鍵依賴接入層Nginx靜態(tài)資源、按 IP 限流、連接復(fù)用limit_req_zone、worker_connections服務(wù)層Spring Boot活動開關(guān)校驗、冪等去重、Redis 預(yù)扣減Lettuce/Jedis 連接池、業(yè)務(wù)線程池存儲層Redis MySQLRedis 保存預(yù)扣余量MySQL 保存訂單和最終庫存唯一索引、條件更新、事務(wù)這里有個很常見的誤會以為 Nginx 層限了流服務(wù)層就可以隨便查數(shù)據(jù)庫。實際上 Nginx 限流只能擋住一部分按 IP 限流擋不住分布式的羊毛黨也擋不住正常用戶在不同設(shè)備上的并發(fā)請求。服務(wù)層的業(yè)務(wù)校驗必須獨立存在Nginx 那一層只負(fù)責(zé)“少放點流量進來”不負(fù)責(zé)“業(yè)務(wù)正確”。存儲層的分工也要講清楚。Redis 里的庫存是“預(yù)扣余量”它的作用是快速拒絕大多數(shù)搶不到的請求提高接口吞吐MySQL 里的庫存才是“最終可信庫存”。為什么不能只信 Redis因為 Redis 可能宕機、可能被清空、可能在主從切換時丟數(shù)據(jù)。所以真正扣減數(shù)據(jù)庫庫存的那一步不能省只是把它挪到流量洪峰之后去執(zhí)行。2.3 方案選型數(shù)據(jù)庫鎖、Redis 預(yù)扣減、MQ 削峰各自適合什么場面圍繞“怎么防止超賣”業(yè)內(nèi)最常被提起的有四類方案。我給它們排個序從最重到最輕。悲觀鎖SELECT ... FOR UPDATE是最直接也最笨的辦法查詢時就把行鎖住同一時間只有一個線程能改庫存。缺點是數(shù)據(jù)庫連接會被長時間占用高并發(fā)下連接池很快就滿了適合 QPS 只有幾百的運營后臺不適合對用戶開放的秒殺接口。樂觀鎖版本號或條件更新比悲觀鎖輕一些用UPDATE ... WHERE stock 0把庫存條件拼進 SQL靠數(shù)據(jù)庫行鎖保證不會扣成負(fù)數(shù)。它能扛住幾千 QPS但高并發(fā)下大量請求在數(shù)據(jù)庫層等待行鎖響應(yīng)時間會明顯拉長。適合業(yè)務(wù)比較重、Redis 不好介入的 ERP 庫存扣減場景——這類“庫存并發(fā)扣減”的思路和秒殺其實完全同源。Redis 預(yù)扣減是目前秒殺系統(tǒng)里最常見的做法。用 Redis 的單線程模型做原子扣減把絕大多數(shù)搶不到的請求擋在 MySQL 之前搶到的人再異步落庫。這套方案在單機 Redis 下就能扛住數(shù)萬 QPS是性價比最高的起手式。MQ 削峰則是在 Redis 預(yù)扣減之后再疊一層把訂單創(chuàng)建請求放到消息隊列里由消費者按固定速率落庫防止突發(fā)寫庫壓力。方案優(yōu)點缺點適用場景數(shù)據(jù)庫悲觀鎖實現(xiàn)簡單、絕對一致連接占用高、吞吐低后臺管理、低并發(fā)數(shù)據(jù)庫樂觀鎖無鎖競爭、實現(xiàn)簡單高并發(fā)下重試多、延遲升高ERP 庫存、中低并發(fā)Redis 預(yù)扣減抗高并發(fā)、響應(yīng)快Redis 宕機需補償機制秒殺、搶購、熱點商品MQ 削峰平滑落庫壓力引入中間件、消息可靠性成本大庫存、復(fù)雜訂單流程我自己的選擇很明確第一版永遠(yuǎn)先上“Redis 預(yù)扣減 數(shù)據(jù)庫兜底”等驗證了真實流量、發(fā)現(xiàn)了瓶頸再決定要不要引入 MQ。別一上來就上 Kafka 和分布式事務(wù)那只會讓你同時面對“并發(fā)問題”和“分布式問題”兩個黑匣子。3. 動手落地用 Spring Boot Redis MySQL 把最小秒殺鏈路跑通3.1 依賴、連接池配置與兩張核心表先搭項目。用 Spring Boot 2.7 以上版本JDK 1.8 或 17 都能編譯依賴只需要spring-boot-starter-web、spring-boot-starter-data-redis、spring-boot-starter-jdbc和 MySQL 驅(qū)動。不需要引入 MyBatis 之外的重型框架JdbcTemplate足夠演示。dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-jdbc/artifactId /dependency dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependencyapplication.yml里有兩組參數(shù)值得注意。數(shù)據(jù)源連接池我用 HikariCPSpring Boot 默認(rèn)maximum-pool-size壓測時從 20 調(diào)到 50但別超過 MySQL 的max_connections否則連接池還沒滿數(shù)據(jù)庫先拒連接了。Redis 的超時時間我習(xí)慣設(shè)成 200ms寧可快速失敗也不要讓 Tomcat 線程卡在 Redis 上等幾秒。spring: datasource: url: jdbc:mysql://127.0.0.1:3306/seckill?useUnicodetruecharacterEncodingutf8mb4 username: root password: your_password hikari: maximum-pool-size: 50 minimum-idle: 5 connection-timeout: 1000 redis: host: 127.0.0.1 port: 6379 timeout: 200ms數(shù)據(jù)庫表只需要兩張。seckill_product保存秒殺商品和庫存seckill_order保存訂單。seckill_order必須建UNIQUE KEY uk_user_sku(user_id, sku_id)這是最后一道防重復(fù)下單的兜底閘門表設(shè)計階段沒有它后面全靠代碼去重遲早會漏。CREATE TABLE seckill_product ( id bigint NOT NULL AUTO_INCREMENT, product_name varchar(128) NOT NULL COMMENT 商品名稱, seckill_stock int NOT NULL DEFAULT 0 COMMENT 秒殺總庫存, seckill_price decimal(10,2) NOT NULL COMMENT 秒殺價格, start_time datetime NOT NULL COMMENT 活動開始時間, end_time datetime NOT NULL COMMENT 活動結(jié)束時間, version int NOT NULL DEFAULT 0 COMMENT 樂觀鎖版本號條件更新時使用, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT秒殺商品表; CREATE TABLE seckill_order ( id bigint NOT NULL AUTO_INCREMENT, user_id bigint NOT NULL COMMENT 用戶ID, sku_id bigint NOT NULL COMMENT 秒殺商品ID, order_no varchar(64) NOT NULL COMMENT 訂單號, status tinyint NOT NULL DEFAULT 0 COMMENT 0處理中 1成功 2失敗, create_time datetime NOT NULL COMMENT 創(chuàng)建時間, PRIMARY KEY (id), UNIQUE KEY uk_user_sku (user_id, sku_id) COMMENT 同一用戶同一商品只能有一條訂單 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT秒殺訂單表;建表邏輯說明seckill_order的唯一索引不是為了省空間而是為了在數(shù)據(jù)庫層攔截“同一個用戶對同一商品重復(fù)下單”。version字段服務(wù)于后面的條件更新也就是用WHERE seckill_stock 0替代應(yīng)用層先查后改避免超賣。3.2 秒殺接口核心Redis Lua 原子扣減、冪等校驗、庫存預(yù)熱秒殺接口的代碼不復(fù)雜難在每一步的先后順序。我的習(xí)慣順序是活動校驗 → 重復(fù)下單校驗 → Redis 原子扣庫存 → 寫已參與集合 → 異步落庫。順序錯了就會出問題比如先扣庫存再查用戶是否已搶過就會讓重復(fù)請求也扣掉庫存。先準(zhǔn)備扣庫存的 Lua 腳本。用 Lua 而不是decrement()的原因很簡單decrement()只能保證“扣減”這個動作是原子的不能保證“庫存大于 0 才扣減”——當(dāng)庫存只剩最后 1 件時并發(fā)請求會把庫存扣成負(fù)數(shù)。Lua 腳本把“檢查庫存”和“扣減庫存”包進同一個 Redis 操作里執(zhí)行這才是真正的原子。/** * 扣減庫存的 Lua 腳本 * 返回 -2 表示 key 不存在說明活動未預(yù)熱 * 返回 -1 表示庫存為 0已售罄 * 返回 1 表示扣減成功。 */ private static final String STOCK_SCRIPT if redis.call(exists, KEYS[1]) 0 then return -2 end; local stock tonumber(redis.call(get, KEYS[1])); if stock 0 then return -1 end; redis.call(decr, KEYS[1]); return 1;;參數(shù)說明KEYS[1]傳入的是庫存 key格式建議統(tǒng)一為seckill:stock:{skuId}。腳本內(nèi)redis.call(exists)是為了區(qū)分“沒有預(yù)熱”和“賣完了”兩種狀態(tài)不要把這兩種情況都返回“已售罄”否則排查問題時會浪費大量時間。接下來是秒殺主方法。核心結(jié)構(gòu)如下Service public class SeckillService { private static final String STOCK_PREFIX seckill:stock:; private static final String ORDER_PREFIX seckill:order:; Autowired private StringRedisTemplate redisTemplate; Autowired private OrderService orderService; Autowired private ThreadPoolTaskExecutor orderExecutor; public Result seckill(Long userId, Long skuId) { // 1. 活動開關(guān)校驗秒殺開始前和結(jié)束后直接拒絕 if (!activityCache.isInProgress(skuId)) { return Result.fail(活動未開始或已結(jié)束); } // 2. 冪等校驗同一用戶同一商品只能參與一次 String orderKey ORDER_PREFIX skuId; Boolean participated redisTemplate.opsForSet().isMember(orderKey, userId.toString()); if (Boolean.TRUE.equals(participated)) { return Result.fail(您已參加過該商品的秒殺); } // 3. Redis Lua 原子扣減庫存 String stockKey STOCK_PREFIX skuId; Long result redisTemplate.execute( new DefaultRedisScript(STOCK_SCRIPT, Long.class), Collections.singletonList(stockKey) ); if (result ! null result -2L) { return Result.fail(活動尚未開放請稍后重試); } if (result ! null result -1L) { return Result.fail(商品已搶完); } // 4. 記錄參與用戶保證后續(xù)請求不會再進來 redisTemplate.opsForSet().add(orderKey, userId.toString()); // 5. 異步落庫立即返回成功提示 orderExecutor.execute(() - { try { orderService.createOrder(userId, skuId); } catch (Exception e) { rollbackStock(userId, skuId); log.error(訂單創(chuàng)建失敗已回補庫存, e); } }); return Result.success(秒殺成功訂單處理中); } }邏輯說明第 3 步的execute通過DefaultRedisScript把 Lua 腳本發(fā)給 Redis整個“檢查扣減”在服務(wù)端完成。第 5 步用線程池異步執(zhí)行接口響應(yīng)時間不會包含數(shù)據(jù)庫寫入耗時這也是高并發(fā)秒殺系統(tǒng)的標(biāo)準(zhǔn)做法——用戶看到的“秒殺成功”不代表訂單已經(jīng)生成只代表庫存已經(jīng)預(yù)扣成功。接著是庫存預(yù)熱。這個步驟極其容易被新手忽略如果活動開始后 Redis 里還沒有庫存數(shù)據(jù)第一個請求執(zhí)行exists就會返回 0所有用戶都會收到“活動尚未開放”。預(yù)熱應(yīng)該在活動開始前 5 分鐘由定時任務(wù)或運營后臺觸發(fā)public void preloadStock(Long skuId) { Integer stock productMapper.selectStockById(skuId); redisTemplate.opsForValue().set(STOCK_PREFIX skuId, String.valueOf(stock)); }參數(shù)說明預(yù)熱時用簡單set即可不需要 Lua?；顒舆M行中如果 Redis 里的 key 過期被刪后續(xù)請求會全部走到“未預(yù)熱”分支所以還要給庫存 key 設(shè)置一個覆蓋完整活動時長的 TTL避免無意的過期擊穿。3.3 異步落庫與線程池參數(shù)createOrder 怎么寫庫存怎么回補異步落庫這一步要處理兩個問題數(shù)據(jù)庫庫存不能扣成負(fù)數(shù)以及 MySQL 扣減失敗后 Redis 庫存要回補。createOrder方法里的關(guān)鍵不是先查庫存再插入訂單而是用條件更新一步完成“檢查庫存 扣減”Transactional public void createOrder(Long userId, Long skuId) { String orderNo generateOrderNo(); // 號段或雪花算法 // 條件更新庫存大于 0 才扣減返回受影響行數(shù) int rows jdbcTemplate.update( UPDATE seckill_product SET seckill_stock seckill_stock - 1, version version 1 WHERE id ? AND seckill_stock 0, skuId ); if (rows 0) { throw new RuntimeException(數(shù)據(jù)庫庫存扣減失敗); } // 插入訂單唯一索引兜底重復(fù)問題 jdbcTemplate.update( INSERT INTO seckill_order (user_id, sku_id, order_no, status, create_time) VALUES (?, ?, ?, 1, NOW()), userId, skuId, orderNo ); }邏輯說明UPDATE ... WHERE seckill_stock 0看起來只有一句 SQL實際由 InnoDB 行鎖保證不可能把庫存扣成負(fù)數(shù)。多個請求同時執(zhí)行這句 SQL 時只有第一個請求能拿到行鎖并成功扣減后面的請求會因為seckill_stock 0條件不成立而返回 0 行。這比“先 SELECT 再 UPDATE”安全得多也比悲觀鎖省數(shù)據(jù)庫連接。異步執(zhí)行需要線程池。線程池大小直接影響吞吐核心線程數(shù)太小會讓任務(wù)排隊太久用戶雖然收到了“秒殺成功”但遲遲等不到訂單。Configuration public class OrderThreadPoolConfig { Bean(orderExecutor) public ThreadPoolTaskExecutor orderExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(8); executor.setMaxPoolSize(32); executor.setQueueCapacity(500); executor.setThreadNamePrefix(order-async-); executor.setRejectedExecutionHandler(new ThreadPoolExecutor.AbortPolicy()); executor.initialize(); return executor; } }參數(shù)說明核心線程數(shù) 8、最大 32、隊列 500是一臺 4C8G 服務(wù)器上的保守配置。隊列長度決定服務(wù)能“吞下”多少個來不及處理的落庫任務(wù)超過 500 后新任務(wù)會被拒絕被拒絕的任務(wù)已經(jīng)在 Redis 扣過庫存所以在主方法里 catch 到RejectedExecutionException時要立刻回補庫存并提示用戶“系統(tǒng)繁忙請稍后重試”?；匮a庫存的方法也需要寫清楚public void rollbackStock(Long userId, Long skuId) { // 回補 Redis 庫存 redisTemplate.opsForValue().increment(STOCK_PREFIX skuId); // 移除用戶參與標(biāo)記允許重新參與 redisTemplate.opsForSet().remove(ORDER_PREFIX skuId, userId.toString()); }很多文章只講回補 Redis 庫存不提移除用戶標(biāo)記結(jié)果用戶明明第一次秒殺失敗重試時卻被冪等校驗擋住造成“庫存沒賣完但用戶全部被拒”的詭異現(xiàn)象?；匮a庫存和移除用戶標(biāo)記必須成對出現(xiàn)。4. 用 JMeter 壓測驗證TPS、TP99 和性能拐點怎么讀4.1 JMeter 線程組設(shè)置3000 并發(fā)模擬的最小壓測計劃寫完了代碼別急著上線先壓測。JMeter 是最容易上手的壓測工具打開后創(chuàng)建一個測試計劃依次添加“線程組”“HTTP 請求”“聚合報告”。線程組配置直接決定壓測結(jié)果是否可信。我推薦第一次壓測按這個表設(shè)置JMeter 字段推薦值設(shè)計理由線程數(shù)3000模擬秒殺活動的瞬時用戶量Ramp-up 周期秒6060 秒內(nèi)逐步發(fā)完 3000 個請求避免一起涌出循環(huán)次數(shù)1秒殺場景每人只搶一次不設(shè)循環(huán)HTTP 請求超時3000 ms與后端接口超時保持一致新手最容易踩的坑是把 Ramp-up 設(shè)成 0。0 意味著所有線程在同一瞬間發(fā)起請求這確實能壓出極限值但和真實用戶行為完全不符——真實用戶是分批涌入的。先用 Ramp-up 60 秒摸清系統(tǒng)的穩(wěn)定能力再用 0 秒摸清極限兩個指標(biāo)分開看。4.2 讀懂聚合報告平均響應(yīng)時間會騙人TP99 才是關(guān)鍵壓測結(jié)束后打開聚合報告重點看四個指標(biāo)。吞吐量Throughput單位是requests/sec表示系統(tǒng)每秒能處理多少請求。比如吞吐量 1200/sec代表一秒鐘處理了 1200 個秒殺請求。錯誤率Error %正常應(yīng)該在 0.5% 以下。如果錯誤率超過 1%先去看服務(wù)端日志別急著調(diào)參數(shù)。錯誤可能是超時、連接拒絕、線程池拒絕也可能是接口邏輯拋異常原因完全不同。90% 和 99% 響應(yīng)時間Percentile這是最容易被忽略的指標(biāo)。平均響應(yīng)時間 50ms 很漂亮但如果 99% 是 900ms說明有 1% 的用戶在系統(tǒng)邊緣等得很痛苦。秒殺場景里99% 響應(yīng)時間大于 1 秒就不能接受。最后是性能拐點。我會從 500 并發(fā)開始壓依次加到 1000、2000、3000、5000。每次記錄吞吐量和錯誤率。當(dāng)響應(yīng)時間驟增、吞吐量開始下降的那一檔并發(fā)數(shù)就是性能拐點。比如 2000 并發(fā)時吞吐量 1800/sec3000 并發(fā)時吞吐量掉到 1500/sec 且錯誤率跳到 5%說明系統(tǒng)在 3000 并發(fā)時已經(jīng)過載這個數(shù)字就是容量上限。4.3 瓶頸定位與調(diào)優(yōu)Tomcat 線程池、Nginx worker、數(shù)據(jù)源連接池壓測發(fā)現(xiàn)瓶頸后按“接入層 → 服務(wù)層 → 存儲層 → JVM”的順序逐個排查。先看 Tomcat 線程池因為它在最前面最容易被流量打滿。Spring Boot 內(nèi)置 Tomcat 默認(rèn)maxThreads200acceptCount100。換句話說同時只能有 200 個請求正在被處理另有 100 個請求在隊列里等待其余直接拒絕。這個默認(rèn)值對秒殺場景太保守了我一般會調(diào)大Connector port8080 protocolorg.apache.coyote.http11.Http11NioProtocol maxThreads800 acceptCount2000 connectionTimeout20000 keepAliveTimeout15000/參數(shù)說明maxThreads控制工作線程數(shù)調(diào)到 800 后能同時處理的請求變多acceptCount是等待隊列長度調(diào)到 2000 意味著最多允許 2000 個請求排隊。要注意別把 maxThreads 調(diào)到 2000 以上線程數(shù)過多會導(dǎo)致 CPU 頻繁切換上下文吞吐反而下降。Nginx 側(cè)關(guān)注兩個參數(shù)worker_processes auto讓進程數(shù)和 CPU 核心數(shù)對齊worker_connections決定每個進程能保持多少連接。秒殺場景連接數(shù)通常會很高20480 是一個合理的起點。worker_processes auto; worker_connections 20480; keepalive_timeout 65;邏輯說明調(diào)大worker_connections不會立刻提升吞吐它的作用是讓 Nginx 不成為連接瓶頸真正限制并發(fā)的是后端 Tomcat 線程池。所以調(diào)優(yōu)順序一定是“后端先調(diào)Nginx 再跟著擴”。數(shù)據(jù)源連接池也需要同步調(diào)整。HikariCP 默認(rèn)maximum-pool-size10壓測時很容易打滿。注意一個約束條件連接池大小不能超過 MySQL 的max_connections默認(rèn) 151如果連接池 50、Tomcat maxThreads 800同時只有 50 個數(shù)據(jù)庫連接可用其余線程都在等待連接。這解釋了為什么 java 面試八股里總強調(diào)“連接池不是越大越好要和上游線程池聯(lián)動看”。JVM 參數(shù)進壓測前就設(shè)好。4C8G 機器給 Spring Boot 預(yù)留 4G 堆-Xms4g -Xmx4g避免壓測過程中頻繁 Full GC 影響響應(yīng)時間。如果壓測時看到 GC 日志密集優(yōu)先解決堆內(nèi)存分配而不是繼續(xù)調(diào)線程池。5. 避坑排查秒殺系統(tǒng)最容易翻車的五個場景逐一對癥解決5.1 超賣問題活動發(fā)了 100 件訂單出了 500 件現(xiàn)象活動結(jié)束后seckill_product的seckill_stock變成負(fù)數(shù)seckill_order里的訂單數(shù)量遠(yuǎn)超活動庫存。原因代碼里用的是“先 SELECT 庫存判斷大于 0再 UPDATE”。并發(fā)下多個請求同時讀到剩余庫存 1 件全部通過判斷全部執(zhí)行 UPDATE庫存被扣成負(fù)數(shù)。解決把應(yīng)用層的“先查后改”改成 SQL 條件更新UPDATE ... SET seckill_stock seckill_stock - 1 WHERE id ? AND seckill_stock 0。如果代碼已經(jīng)上線臨時止血可以給庫存表加一個CHECK (seckill_stock 0)約束MySQL 8.0 支持 CHECK 約束能阻止后續(xù)產(chǎn)生負(fù)庫存但歷史臟數(shù)據(jù)需要單獨對賬修復(fù)。5.2 Redis 售罄但數(shù)據(jù)庫還有貨庫存對不上的經(jīng)典僵局現(xiàn)象用戶看到“已搶完”但運營后臺里商品庫存還剩幾十件。查 Redis 發(fā)現(xiàn)庫存 key 為 0查 MySQL 發(fā)現(xiàn)庫存還有 30。原因Redis 預(yù)扣減成功后異步落庫失敗。比如數(shù)據(jù)庫線程池滿了、訂單插入超時、事務(wù)回滾導(dǎo)致 Redis 扣了庫存但 MySQL 沒扣。這時如果沒有回補邏輯Redis 和 MySQL 的庫存就會永久不一致。解決一是異步任務(wù)里要 catch 所有異常失敗后調(diào)用rollbackStock回補 Redis 庫存并移除用戶標(biāo)記二是增加一個定時對賬任務(wù)每 5 分鐘掃描 Redis 中庫存接近 0 的商品和 MySQL 的實際剩余庫存做比對發(fā)現(xiàn)差值就觸發(fā)校正。這個對賬任務(wù)不復(fù)雜但能救你于水火尤其是活動進行中沒人敢動 Redis 數(shù)據(jù)的尷尬時刻。5.3 同一用戶重復(fù)下單冪等校驗漏了數(shù)據(jù)庫唯一索引現(xiàn)象活動結(jié)束后發(fā)現(xiàn)同一個user_id對同一個sku_id有三四條訂單記錄用戶明明只搶到一次。原因代碼里用 Redis Set 做冪等校驗但 Redis 記錄在異步落庫時被清掉或過期或者用戶繞過正常接口直接調(diào)用下單接口。Redis 不是數(shù)據(jù)庫它的數(shù)據(jù)可能丟失必須靠數(shù)據(jù)庫層兜底。解決兩層防御并行。第一層是 Redis Set 的isMember校驗攔截正常用戶的重試請求第二層是seckill_order表上的UNIQUE KEY uk_user_sku(user_id, sku_id)。當(dāng)重復(fù)插入觸發(fā)唯一鍵沖突時捕獲DuplicateKeyException按“用戶已參與”處理而不是直接拋出 500。記住Redis 去重是性能優(yōu)化MySQL 唯一索引才是最終防線。5.4 壓測時大量 500Tomcat 線程池被打穿現(xiàn)象壓測并發(fā)數(shù)超過 2000 后聚合報告錯誤率飆升到 10% 以上服務(wù)端日志大量出現(xiàn)“RejectedExecutionException”或“Connection timed out”。原因Spring Boot 內(nèi)置 Tomcat 默認(rèn)maxThreads2002000 并發(fā)下大部分請求在acceptCount100的等待隊列里排隊隊列滿了直接拒絕連接部分請求就算進入處理流程也會因為數(shù)據(jù)庫連接池不足而等待超時。解決按前面第 4.3 節(jié)的參數(shù)調(diào)整 Tomcat 線程池和 HikariCP 連接池同時在秒殺接口最外層加限流讓超過系統(tǒng)處理能力的請求直接返回“系統(tǒng)繁忙”。要用好AbortPolicy并捕獲RejectedExecutionException這是線程池自帶的流量保護機制別因為怕失敗而把它關(guān)掉。5.5 秒殺結(jié)束還有流量進來活動開關(guān)沒擋住現(xiàn)象活動結(jié)束 1 小時后接口還在產(chǎn)生訂單商品鏈接還能下單。原因代碼里做了活動時間校驗但校驗用的是服務(wù)器本地時間加數(shù)據(jù)庫活動表活動結(jié)束時可能有少量請求恰好卡在邊界上更常見的是運營直接改數(shù)據(jù)庫活動時間緩存里的活動狀態(tài)沒有同步更新。解決把活動狀態(tài)緩存到 Redis活動開始前設(shè)置一個“待開始”狀態(tài)開始后由定時任務(wù)或手動發(fā)布改成“進行中”結(jié)束后改成“已結(jié)束”。接口層面做雙層判斷先查 Redis 狀態(tài)快速攔截大多數(shù)無效請求再查數(shù)據(jù)庫時間精確兜底?；顒咏Y(jié)束后應(yīng)立刻在 Nginx 層把 URL 的流量轉(zhuǎn)發(fā)到靜態(tài)頁或活動結(jié)束頁而不是讓請求到達(dá)后端。接住這些流量的成本很低漏掉它們就會變成驚群效應(yīng)讓數(shù)據(jù)庫在活動結(jié)束后的峰值里繼續(xù)被沖擊。6. 進階優(yōu)化分布式鎖、熱點 key 分片與上線前檢查清單6.1 把冪等和扣減合進一個 Lua減一次網(wǎng)絡(luò)往返到這一步你的單體秒殺已經(jīng)能跑了。如果想優(yōu)化性能第一個動作不是換中間件而是把“判斷是否已參與”和“扣減庫存”這兩個 Redis 操作合并成一個 Lua 腳本。當(dāng)前實現(xiàn)的兩次 Redis 調(diào)用各消耗一次網(wǎng)絡(luò)往返合并后可以省掉一半的延遲。-- KEYS[1] 庫存 key -- KEYS[2] 用戶已購 set key -- ARGV[1] 用戶ID if redis.call(sismember, KEYS[2], ARGV[1]) 1 then return -3 end if redis.call(exists, KEYS[1]) 0 then return -2 end local stock tonumber(redis.call(get, KEYS[1])) if stock 0 then return -1 end redis.call(decr, KEYS[1]) redis.call(sadd, KEYS[2], ARGV[1]) return 1邏輯說明腳本里用sismember判斷用戶是否已搶過已搶過直接返回 -3。注意這里的數(shù)據(jù)一致性問題——如果用戶在請求 A 里搶成功又在同一毫秒發(fā)出請求 B兩個請求都進到 Lua 腳本里執(zhí)行。Redis 單線程會保證這兩個腳本串行執(zhí)行所以不會出現(xiàn)“兩個腳本同時通過庫存檢查”的情況。這也是為什么秒殺系統(tǒng)天然適合 Redis單線程執(zhí)行模型省掉了應(yīng)用層分布式鎖。6.2 熱點商品 key 分片別再讓一個 Redis key 扛全部流量當(dāng)一個商品特別火爆所有請求都打在同一個 Redis key 上單實例 Redis 的 CPU 會先到瓶頸。常見做法是對庫存 key 做分片把 100 件庫存拆成 10 個小 key每個 key 存 10 件請求進來時根據(jù)用戶 ID 取模路由到不同的小 key。int shard (int) (userId % 10); String stockKey seckill:stock: skuId : shard;參數(shù)說明分片數(shù)是經(jīng)驗值單機 Redis 4 到 8 個分片足夠分片后的副作用是部分分片賣完、部分分片還有剩余需要在服務(wù)端匯總剩余庫存再做“是否還有貨”的判斷。庫存回補時也要遍歷所有分片。這個優(yōu)化適合秒殺量極大、已確認(rèn) Redis 是瓶頸時再上前期不必做。6.3 上線前檢查清單照著過一遍再開閘最后是一份自檢清單是我每次上線秒殺活動前必做的一套動作第一預(yù)熱腳本是否已執(zhí)行Redis 里所有商品的庫存 key 都存在且數(shù)值正確第二超賣核對 SQL 是否準(zhǔn)備好活動結(jié)束后跑一遍seckill_product和seckill_order的對賬確認(rèn)沒有訂單數(shù)大于庫存數(shù)第三異步線程池的監(jiān)控是否接入隊列積壓何時超過閾值要能收到告警第四檢查回補庫存的日志有沒有輸出一旦出現(xiàn)“訂單創(chuàng)建失敗已回補庫存”要立刻排查原因第五把壓測報告和真實預(yù)估流量對比確認(rèn)性能拐點高于預(yù)估峰值 30% 以上再開閘。做秒殺這類系統(tǒng)我自己的習(xí)慣是永遠(yuǎn)讓第一版保持單體和簡單先把 Redis 預(yù)扣減、冪等校驗、異步落庫這條鏈路的每一環(huán)跑通確認(rèn)超賣和重復(fù)下單都不再出現(xiàn)再考慮分布式鎖、庫存分片和消息隊列。分布式的東西只有在單點確實扛不住時才值得引入——你手上的秒殺系統(tǒng)也一樣先把手里的單體調(diào)出穩(wěn)定的 2000 QPS比直接搭一套半懂不懂的微服務(wù)更有價值。希望幫到你。本文還有配套的精品資源點擊獲取