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