秒殺幾乎是Java后端面試?yán)锢@不開的“高并發(fā)試金石”。Spring Boot、Kafka、Redis 這三件套是電商秒殺方案里最常被問到的組合。面試官只要問出“讓你設(shè)計(jì)一個秒殺系統(tǒng)你怎么做”大概率就是想從流量削峰、庫存扣減、數(shù)據(jù)一致性這三個維度看你有沒有真實(shí)項(xiàng)目經(jīng)驗(yàn)。落到技術(shù)棧上Spring Boot 負(fù)責(zé)搭起整體工程Redis 在前端扛住讀請求和分布式鎖Kafka 在中間做異步削峰這套組合已經(jīng)是電商場景的標(biāo)準(zhǔn)答案。但標(biāo)準(zhǔn)答案和線上能穩(wěn)定跑通的方案之間隔著大量細(xì)節(jié)坑比如 Redis 分布式鎖續(xù)期、Kafka 消息順序性、緩存與數(shù)據(jù)庫一致性每一條我都踩過。這篇實(shí)錄沒有教科書式的廢話適合正準(zhǔn)備跳槽的 Java 開發(fā)也適合已經(jīng)把 CRUD 寫得很熟、想往高并發(fā)方向突破的工程師。我會從整體方案設(shè)計(jì)講起再落到 Spring Boot 工程里的核心代碼最后把面試官最常追問的高頻問題和線上排查經(jīng)驗(yàn)一起給你。你不需要一次全背下來但建議先理解每層設(shè)計(jì)要解決什么問題后面看代碼和面試答案會輕松很多。1. 電商秒殺場景的整體方案設(shè)計(jì)1.1 秒殺為什么難流量模型與核心矛盾先看流量模型。普通業(yè)務(wù)接口的 QPS 可能就幾百秒殺開場那幾秒流量往往達(dá)到平時的幾十倍甚至上百倍而且用戶像潮水一樣涌進(jìn)來。數(shù)據(jù)庫連接池一般也就 50~100 個連接一個慢 SQL 就能把連接池打滿更別說秒殺瞬間的寫入壓力。所以你會發(fā)現(xiàn)所有秒殺方案本質(zhì)上都在解決同一個矛盾有限的數(shù)據(jù)庫處理能力 vs 瞬間爆發(fā)的海量請求。既然處理不過來思路就變成“讓請求在到達(dá)數(shù)據(jù)庫之前盡量被攔截、排隊(duì)或丟棄”。后端常見手段有四級瀏覽器/CDN 限流、Nginx 層限流、Redis 層攔截、Kafka 層削峰。前兩級是擋無效流量后兩級才是保護(hù)訂單系統(tǒng)。秒殺結(jié)果本來就只有少數(shù)人能搶到所以系統(tǒng)設(shè)計(jì)的第一原則不是“每個請求都成功”而是“保證成功請求不丟、庫存不超賣、數(shù)據(jù)最終一致”。這里要注意一個思維轉(zhuǎn)換很多新手一上來就想著“怎么優(yōu)化數(shù)據(jù)庫”其實(shí)秒殺最忌諱讓數(shù)據(jù)庫直接面對峰值流量。數(shù)據(jù)庫在秒殺里扮演的角色應(yīng)當(dāng)是最終流水存儲而不是實(shí)時請求處理。把數(shù)據(jù)庫往后放前面用 Redis 和 Kafka 頂住才是正確的架構(gòu)方向。1.2 三層削峰方案前端限流、Redis 緩存與 Kafka 異步削峰從用戶點(diǎn)擊“立即搶購”到最后收到訂單結(jié)果我習(xí)慣把秒殺鏈路分成三段來設(shè)計(jì)。第一段是請求接入層。用戶請求先進(jìn) Nginx通過 OpenResty 的 lua-resty-limit-traffic 做令牌桶限流每秒只放行比如 1 萬請求超過直接返回“限流中”。這一層能防住一部分腳本刷單。再往下后端接口在 Spring Boot 層面用 Guava RateLimiter 或 Resilience4j 做單機(jī)限流防止單節(jié)點(diǎn)被沖垮。很多人忽略這一層但線上秒殺如果沒有接入層限流后面 Redis 壓力再小也會被無效請求打滿。第二段是Redis 預(yù)扣庫存。秒殺接口的第一步不是寫數(shù)據(jù)庫而是先查 Redis 里的庫存再通過 Lua 腳本完成“檢查庫存 校驗(yàn)是否已購買 扣減庫存”。Lua 腳本可以保證原子性避免超賣。庫存數(shù)據(jù)在秒殺開始前從數(shù)據(jù)庫預(yù)熱到 Redis秒殺結(jié)束后再異步同步回?cái)?shù)據(jù)庫。Redis 能抗的 QPS 在十萬級別用來做瞬間攔截再合適不過。第三段是Kafka 異步下單。Redis 預(yù)扣成功后只說明用戶“搶到了資格”真正的訂單創(chuàng)建、扣減數(shù)據(jù)庫庫存、生成支付記錄等動作放到 Kafka 消息里由訂單服務(wù)異步消費(fèi)。這樣數(shù)據(jù)庫收到的寫入頻率就被拉平了從峰值每秒幾萬變成每秒幾百上千。消費(fèi)端做一定的批量處理還能進(jìn)一步提高吞吐。這套三段式方案的好處是每一層都在做“減負(fù)”。流量到數(shù)據(jù)庫之前已經(jīng)過了一層層的漏斗真正落到數(shù)據(jù)庫的寫操作數(shù)量級大幅下降。面試時我們講方案不需要把每層代碼都背出來但一定要講清楚每一層攔截了什么流量、為什么要放在這一層。2. Spring Boot 工程落地接口分層與并發(fā)控制2.1 秒殺接口的核心流程預(yù)扣庫存、校驗(yàn)重復(fù)、異步下單用 Spring Boot 寫一個秒殺接口代碼上其實(shí)不復(fù)雜復(fù)雜的是并發(fā)控制。我習(xí)慣把接口拆成三步請求校驗(yàn)、Redis 預(yù)扣、發(fā)送 Kafka 消息。第一步請求校驗(yàn)包括參數(shù)合法性、用戶是否登錄、活動是否已開始/結(jié)束。這些校驗(yàn)要在 Redis 預(yù)扣之前做干凈否則一個非法參數(shù)就可能浪費(fèi)一次庫存扣減。第二步調(diào) Redis Lua 腳本預(yù)扣庫存這一步同時完成“庫存 0 判斷”和“扣減”兩個動作確保原子。第三步如果扣減成功就封裝一個 OrderMessage 發(fā)給 Kafka由下游服務(wù)創(chuàng)建訂單。有一個非常容易被忽視的點(diǎn)發(fā)送 Kafka 消息放在 Redis 扣減成功之后但如果在發(fā)送消息前服務(wù)宕機(jī)了用戶明明搶到了資格訂單卻永遠(yuǎn)不生成。所以工程上不能簡單發(fā)了就完事。我這邊用的方案是預(yù)扣成功后先把一條“待創(chuàng)建訂單”記錄寫入本地?cái)?shù)據(jù)庫或者寫一個訂單流水表狀態(tài)是“待處理”然后發(fā)消息消費(fèi)端處理成功后回寫狀態(tài)。如果發(fā)消息失敗或消費(fèi)失敗由一個定時任務(wù)掃描待處理訂單重新投遞消息。這個“本地消息表 定時對賬”的思路下面講數(shù)據(jù)一致性時會詳細(xì)說。2.2 Redis 分布式鎖的正確寫法與續(xù)期問題秒殺里最容易被面試官追問的就是 Redis 分布式鎖。很多網(wǎng)上的教程還在教 setnx expire但真正生產(chǎn)環(huán)境這樣寫至少有兩個坑一是 setnx 后服務(wù)崩了沒有設(shè)置過期時間鎖永遠(yuǎn)不釋放二是鎖過期時間太短業(yè)務(wù)還沒執(zhí)行完鎖就自動釋放了另一個線程進(jìn)來造成并發(fā)覆蓋。正確的寫法是用SET key value NX EX timeout這一條命令完成加鎖和設(shè)置過期時間value 必須是唯一標(biāo)識比如 UUID 或業(yè)務(wù)訂單號。釋放鎖的時候不能直接 del而要先用 Lua 比較 value 是否是自己是自己的才 del避免誤刪別人的鎖。原因很簡單如果線程 A 執(zhí)行時間過長鎖過期了線程 B 拿到鎖開始執(zhí)行A 執(zhí)行完直接 del就會把 B 的鎖刪掉。再說續(xù)期。高版本 Redis 客戶端推薦用 Redisson 的 watchdog 機(jī)制默認(rèn)鎖的租期是 30 秒每 10 秒自動續(xù)期。如果業(yè)務(wù)執(zhí)行完了就釋放鎖不用關(guān)心續(xù)期如果服務(wù)宕機(jī)了鎖也會因?yàn)樽馄诘狡谧詣俞尫挪粫梨i。這比自己寫 Timer 續(xù)期安全得多。我見過不少為了省依賴自己實(shí)現(xiàn)續(xù)期的最后要么少續(xù)期導(dǎo)致鎖提前釋放要么忘了釋放導(dǎo)致死鎖。能用 Redisson 就用 Redisson面試時可以提一嘴看門狗機(jī)制會很加分。2.3 數(shù)據(jù)一致性緩存與數(shù)據(jù)庫的最終一致性秒殺里 Redis 庫存是“前置庫存”數(shù)據(jù)庫庫存是“最終庫存”。理論上兩個值最終要一致但不可能實(shí)時一致所以必須接受“最終一致性”。怎么保證我的做法是扣減 Redis 時記錄一條庫存流水流水表里帶本次扣減的唯一訂單號Kafka 消費(fèi)者收到消息后在數(shù)據(jù)庫本地事務(wù)里同時完成“扣減數(shù)據(jù)庫庫存 更新庫存流水狀態(tài) 創(chuàng)建訂單”如果數(shù)據(jù)庫扣減成功但 Kafka 消費(fèi)失敗流水表里會有一直處于“待處理”的數(shù)據(jù)由定時任務(wù)掃描并重發(fā)如果數(shù)據(jù)庫庫存不足或消費(fèi)端業(yè)務(wù)失敗需要回補(bǔ) Redis 庫存?；匮a(bǔ)操作同樣先寫流水再通過消息或直接調(diào)用來恢復(fù) Redis。這套“流水 對賬”機(jī)制是一個通用保底方案面試?yán)镆欢ㄒv清楚因?yàn)樗瑫r回答了“消息丟失怎么辦”“消費(fèi)失敗怎么辦”“Redis 和數(shù)據(jù)庫不一致怎么辦”三個問題。至于用不用分布式事務(wù)我的觀點(diǎn)是秒殺這種高并發(fā)場景盡量規(guī)避強(qiáng)分布式事務(wù)因?yàn)?XA 事務(wù)會鎖資源、拖垮性能。用本地消息表和最終一致性就好。3. Kafka 消息中間件在秒殺中的實(shí)戰(zhàn)配置3.1 為什么用 Kafka削峰填谷與流量整形秒殺場景選消息隊(duì)列Kafka 是首選。相比 RabbitMQ、RocketMQKafka 的吞吐更高、分區(qū)模型更適合并行消費(fèi)而且在大促場景下有成熟的“削峰填谷”能力。所謂削峰填谷就是生產(chǎn)者把高峰期的大量消息快速寫入 Kafka消費(fèi)者按自己的節(jié)奏慢慢消費(fèi)。從時間維度看請求的“峰”被削掉了數(shù)據(jù)庫處理的“谷”被填平了整體負(fù)載平穩(wěn)。Kafka 寫入延遲極低生產(chǎn)端吞吐可達(dá)每秒幾十萬條這點(diǎn)對秒殺特別重要。消費(fèi)者雖然默認(rèn)單線程但可以通過增加分區(qū)數(shù)和消費(fèi)者實(shí)例數(shù)并行消費(fèi)。每個分區(qū)只能被同一個消費(fèi)組內(nèi)的一個消費(fèi)者實(shí)例消費(fèi)分區(qū)數(shù)是并行消費(fèi)的上限。所以大促前我會把秒殺訂單 topic 的分區(qū)數(shù)提前設(shè)置成 16 或 32而不是用默認(rèn)的 1。后續(xù)想擴(kuò)容分區(qū)會比較麻煩需要提前規(guī)劃。3.2 生產(chǎn)端與消費(fèi)端的幾個關(guān)鍵參數(shù)陷阱先說生產(chǎn)端。Kafka 單條消息默認(rèn)最大 1MBtopic 的 max.message.bytes 默認(rèn)也是 1MB。如果訂單消息里塞了完整的商品快照、優(yōu)惠券詳情甚至營銷日志很容易踩到“Record is too large”的坑。我的經(jīng)驗(yàn)是消息體里只放訂單號、用戶 ID、商品 ID、數(shù)量、秒殺活動 ID 等必要字段其他詳情由消費(fèi)端去查緩存或數(shù)據(jù)庫。實(shí)在要傳大對象需要在 broker 端調(diào)大 message.max.bytes但帶來的網(wǎng)絡(luò)和存儲開銷也會變大非必要不建議。消費(fèi)端有幾個容易踩的配置enable.auto.commit 默認(rèn) true處理邏輯復(fù)雜時容易消息還沒處理完就自動提交了 offset服務(wù)重啟后會丟消息。建議設(shè)為 false手動提交并等業(yè)務(wù)處理完成后提交。max.poll.interval.ms 默認(rèn) 300 秒如果單條消息處理耗時超過這個時間消費(fèi)者會被踢出消費(fèi)組觸發(fā) rebalance。秒殺訂單處理里要避免在消費(fèi)線程里做長任務(wù)比如遠(yuǎn)程調(diào)用、慢 SQL盡量做成異步化或批量化。消費(fèi)線程數(shù)不要超過分區(qū)數(shù)。用多線程消費(fèi)時如果同一訂單的重試消息落到不同分區(qū)順序就無法保證。要保序只能犧牲并行度一個分區(qū)一個線程或者按訂單號哈希到固定分區(qū)。3.3 Kafka 消息積壓與消費(fèi)延遲的排查實(shí)錄線上秒殺最常見的故障就是“消息積壓”?，F(xiàn)象是 Redis 已扣庫存但用戶遲遲出不來訂單結(jié)果。排查路徑大概是第一步看 Kafka 消費(fèi)組 lag。用命令行工具kafka-consumer-groups.sh --describe --group order_group看每個分區(qū)的 lag 數(shù)。lag 持續(xù)增長說明消費(fèi)能力跟不上生產(chǎn)速度或消費(fèi)者卡住了。第二步看消費(fèi)者日志有沒有頻繁 rebalance。rebalance 會導(dǎo)致消費(fèi)暫停。常見原因是 max.poll.interval.ms 設(shè)置太短、處理耗時超時或消費(fèi)者實(shí)例頻繁宕機(jī)。rebalance 期間分區(qū)的 offset 可能要重新分配也會放大延遲。第三步看下游數(shù)據(jù)庫連接池和慢 SQL。很多時候 Kafka 不背鍋而是消費(fèi)線程在等數(shù)據(jù)庫連接。秒殺訂單服務(wù)要把數(shù)據(jù)庫連接池從默認(rèn)的 10 個調(diào)大壓測時觀察活躍連接數(shù)和等待線程數(shù)。我遇到過“消息積壓 10 萬”的報(bào)警最后排查是消費(fèi)端一個查詢商品詳情的 SQL 沒走索引單條處理從 5ms 變成 300ms直接拖垮了消費(fèi)速度。優(yōu)化后 lag 幾分鐘就清掉了。排查這種事靠經(jīng)驗(yàn)也靠工具?？梢暬ぞ呖梢匝b Offset Explorer原 Kafka Tool看 cluster、topic、consumer group 的 lag 非常直觀不用每次都敲命令。4. 面試高頻問題匯總與避坑指南4.1 Redis 緩存穿透、擊穿、雪崩的區(qū)別與應(yīng)對這是 Java 大廠面試的基礎(chǔ)題但放在秒殺場景里問就成了進(jìn)階題。三者的區(qū)別簡單說穿透查一個根本不存在的數(shù)據(jù)比如偽造的商品 ID緩存和數(shù)據(jù)庫都沒有導(dǎo)致每次請求都打數(shù)據(jù)庫。擊穿熱點(diǎn) key 在緩存過期的一瞬間大量請求同時打到數(shù)據(jù)庫。雪崩大量 key 在同一時間過期或者 Redis 宕機(jī)導(dǎo)致請求全部落到數(shù)據(jù)庫。秒殺場景里擊穿是重點(diǎn)。秒殺商品的庫存 key 是絕對熱點(diǎn)一旦過期瞬間所有請求都會去數(shù)據(jù)庫查庫數(shù)據(jù)庫必掛。應(yīng)對方案有幾種熱點(diǎn) key 永不過期或者設(shè)置邏輯過期時間由后臺任務(wù)異步更新加互斥鎖緩存未命中時只讓一個線程去查數(shù)據(jù)庫其他線程等待后回源還有多級緩存本地 Caffeine 或 Redis 副本兜底。穿透的應(yīng)對是布隆過濾器或緩存空值并設(shè)置短過期時間。雪崩則需要加隨機(jī)過期時間、做 Redis 高可用、限流降級。這些都要作為方案的一部分講給面試官不要只背概念要結(jié)合秒殺鏈路的哪一環(huán)會出現(xiàn)每種問題。4.2 Kafka 重復(fù)消費(fèi)與 Redis 冪等性設(shè)計(jì)消息隊(duì)列不丟消息很難做到“恰好一次”所以消費(fèi)端必須做冪等。秒殺訂單場景的重復(fù)消費(fèi)主要有兩種來源一是生產(chǎn)者發(fā)送時服務(wù)重試導(dǎo)致同一條消息發(fā)了兩遍二是消費(fèi)端處理成功后還沒來得及提交 offset 就宕機(jī)重啟后又消費(fèi)一遍。冪等設(shè)計(jì)我常用三種方案數(shù)據(jù)庫唯一鍵約束。訂單流水表用“用戶ID 秒殺活動ID 商品ID”建唯一索引重復(fù)插入時數(shù)據(jù)庫報(bào) duplicate key捕獲后直接返回成功。Redis 冪等標(biāo)記。每個用戶搶購前先把用戶ID寫入 Redis SETNX設(shè)置過期時間如果已經(jīng)存在則拒絕。這是業(yè)務(wù)層的重復(fù)請求攔截。本地去重表 狀態(tài)機(jī)。消費(fèi)消息后先查流水表狀態(tài)已經(jīng)“處理中”或“已完成”就不重復(fù)處理。這三種可以疊加使用。面試時提到“消費(fèi)端必須冪等”然后說出具體怎么設(shè)計(jì)比單純喊口號強(qiáng)很多。4.3 分布式事務(wù)與最終一致性本地消息表 vs 事務(wù)消息秒殺鏈路里“扣減庫存、創(chuàng)建訂單、增加積分、推送通知”分布在多個服務(wù)里數(shù)據(jù)庫沒辦法用本地事務(wù)一把梭這就涉及分布式事務(wù)。我從來不用強(qiáng)一致方案而是用最終一致性。兩種主流實(shí)現(xiàn)一是本地消息表。在業(yè)務(wù)數(shù)據(jù)庫中維護(hù)一張消息表業(yè)務(wù)操作和消息寫入在同一個本地事務(wù)里提交。然后有一個定時任務(wù)把消息表中狀態(tài)為“待發(fā)送”的記錄發(fā)給 MQ成功后再更新狀態(tài)。這樣做的好處是簡單可靠壞處是消息表和業(yè)務(wù)表耦合且對數(shù)據(jù)庫有一定額外壓力。二是事務(wù)消息。RocketMQ 支持事務(wù)消息Kafka 生態(tài)里對應(yīng) Exactly Once 和 Kafka Streams 更復(fù)雜通常不直接用。如果我們強(qiáng)制用 Kafka 做分布式事務(wù)一般還是“本地消息表 Kafka”的組合。所以面試時你可以說Kafka 生態(tài)下我更傾向本地消息表如果架構(gòu)里用了 RocketMQ可以選用事務(wù)消息配合回查。所謂“回查”就是事務(wù)消息發(fā)送到 MQ 后如果事務(wù)未提交MQ 會反向調(diào)用生產(chǎn)者的接口查一下本地事務(wù)狀態(tài)。這個機(jī)制保證了“本地事務(wù)成功但消息沒發(fā)出去”也不會丟。能把這些區(qū)別講明白面試官就知道你是真寫過。4.4 面試現(xiàn)場如何回答“秒殺系統(tǒng)的設(shè)計(jì)”很多候選人對方案很熟但回答時沒有框架東講一句西講一句。我建議按下面這個順序組織答案先說核心矛盾瞬時流量 vs 數(shù)據(jù)庫有限處理能力。再說總體架構(gòu)接入層限流 - Redis 預(yù)扣庫存 - Kafka 異步下單 - 數(shù)據(jù)庫最終落庫。重點(diǎn)講三個關(guān)鍵點(diǎn)如何防超賣Redis Lua 原子扣減、如何防重復(fù)冪等設(shè)計(jì)、如何保證最終一致本地消息表/對賬。最后補(bǔ)充高可用Redis 哨兵/Cluster、Kafka 多副本、數(shù)據(jù)庫主從、降級策略。這個順序符合“問題 - 方案 - 細(xì)節(jié) - 保障”的邏輯面試官就算追問細(xì)節(jié)你也能穩(wěn)穩(wěn)接住。千萬不要一上來就背 Redis 命令讓人覺得你只是看過八股文。5. 實(shí)操復(fù)盤一個可復(fù)現(xiàn)的秒殺 Demo 核心代碼5.1 環(huán)境準(zhǔn)備與基礎(chǔ)配置本地跑一個最小原型推薦用 Docker 一次性把 Redis 和 Kafka 拉起來。如果你用的是 IntelliJ IDEA 社區(qū)版也可以正常創(chuàng)建 Spring Boot 項(xiàng)目社區(qū)版只是少了 Spring Initializr 的向?qū)О粹o去 start.spring.io 手動生成壓縮包導(dǎo)入 IDEA 即可。個人開發(fā)足夠用。先用 Docker 起服務(wù)寫一個 docker-compose.ymlversion: 3 services: redis: image: redis:7-alpine ports: - 6379:6379 zookeeper: image: bitnami/zookeeper:3.8 ports: - 2181:2181 environment: - ALLOW_ANONYMOUS_LOGINyes kafka: image: bitnami/kafka:3.4 ports: - 9092:9092 environment: - KAFKA_BROKER_ID1 - KAFKA_CFG_ZOOKEEPER_CONNECTzookeeper:2181 - KAFKA_CFG_LISTENERSPLAINTEXT://:9092 - KAFKA_CFG_ADVERTISED_LISTENERSPLAINTEXT://localhost:9092 - ALLOW_PLAINTEXT_LISTENERyes depends_on: - zookeeper本地單節(jié)點(diǎn)夠用。如果面試或工作中要搭集群至少三臺 broker配置 KAFKA_CFG_BROKER_ID 分別為 1、2、3并修改 advertised.listeners 使用各自內(nèi)網(wǎng) IP。集群的價(jià)值在副本默認(rèn) replication.factor 至少 2否則一臺 broker 掛了分區(qū)沒有副本生產(chǎn)環(huán)境會出大事。Spring Boot 項(xiàng)目里引入依賴dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency dependency groupIdorg.springframework.kafka/groupId artifactIdspring-kafka/artifactId /dependency配置 application.ymlspring: redis: host: localhost port: 6379 kafka: bootstrap-servers: localhost:9092 producer: key-serializer: org.apache.kafka.common.serialization.StringSerializer value-serializer: org.apache.kafka.common.serialization.StringSerializer acks: all retries: 3 consumer: group-id: seckill-order-group enable-auto-commit: false key-deserializer: org.apache.kafka.common.serialization.StringDeserializer value-deserializer: org.apache.kafka.common.serialization.StringDeserializer auto-offset-reset: latest listener: ack-mode: manual_immediate這里有幾個參數(shù)我解釋一下。acksall 表示生產(chǎn)者要等所有 ISR 副本都寫入成功才返回保證消息不丟代價(jià)是吞吐略降但秒殺場景下可靠優(yōu)先。enable-auto-commitfalse ack-modemanual_immediate 表示消費(fèi)者手動提交 offset拿到消息處理完后立即提交避免處理中出問題導(dǎo)致 offset 丟失。auto-offset-resetlatest 表示消費(fèi)者啟動后從最新 offset 開始消費(fèi)秒殺場景通常不接受回放老消息所以用 latest如果你要做補(bǔ)償掃描再單獨(dú)用 earliest。5.2 秒殺接口核心代碼與解釋先定義一個 Redis Lua 腳本做原子性的庫存預(yù)扣和防重復(fù)。RedisTemplate 序列化這里有個大坑很多人存進(jìn)去是字符串取出來卻報(bào)類型錯誤。原因是用默認(rèn)的 JdkSerializationRedisSerializer 把對象序列化成了二進(jìn)制。我在配置里統(tǒng)一把 key 和 value 改成 StringRedisSerializer需要存對象時再用 JSON 序列化這樣可讀性也更好。Redis 扣庫存腳本如下注意 KEYS[1] 是庫存 keyKEYS[2] 是用戶去重 keyARGV[1] 是用戶 IDARGV[2] 是扣減數(shù)量ARGV[3] 是去重 key 的過期時間local stock redis.call(get, KEYS[1]) if not stock or tonumber(stock) tonumber(ARGV[2]) then return 0 end local bought redis.call(sismember, KEYS[2], ARGV[1]) if bought 1 then return 2 end redis.call(decrby, KEYS[1], ARGV[2]) redis.call(sadd, KEYS[2], ARGV[1]) redis.call(expire, KEYS[2], ARGV[3]) return 1解釋一下返回 0 表示庫存不足返回 2 表示重復(fù)秒殺返回 1 表示扣減成功。用戶去重集合單獨(dú)設(shè)置過期時間避免 key 一直占內(nèi)存。這個腳本把“查庫存、查重復(fù)、減庫存、記錄用戶”放在一個 Lua 里執(zhí)行Redis 單線程保證原子性不會出現(xiàn)兩個請求同時讀到庫存 1 然后都扣減成功的情況。接著是秒殺接口的 Service 方法核心代碼Service public class SeckillService { Autowired private StringRedisTemplate redisTemplate; Autowired private KafkaTemplateString, String kafkaTemplate; private static final String STOCK_KEY seckill:stock:1001; private static final String BUY_KEY seckill:buy:1001; // DefaultRedisScript 初始化省略 public long seckill(Long userId, Long goodsId, Integer count) { // 前置校驗(yàn)省略 ListString keys Arrays.asList(STOCK_KEY, BUY_KEY); Object result redisTemplate.execute( SECKILL_SCRIPT, keys, userId.toString(), count.toString(), 86400 ); long code Long.parseLong(result.toString()); if (code 1) { // 構(gòu)建訂單消息發(fā)送到 Kafka OrderMessage message new OrderMessage(); message.setUserId(userId); message.setGoodsId(goodsId); message.setCount(count); kafkaTemplate.send(seckill-order-topic, userId.toString(), JSON.toJSONString(message)); } return code; } }發(fā)送消息時把用戶 ID 作為 key目的是讓同一個用戶的訂單消息始終進(jìn)入同一個分區(qū)這樣消費(fèi)端可以按照用戶維度保證順序。Kafka 的分區(qū)器會用 key 的哈希值選分區(qū)這一點(diǎn)對后續(xù)消費(fèi)順序很重要。消費(fèi)端代碼Component public class SeckillOrderConsumer { KafkaListener(topics seckill-order-topic, groupId seckill-order-group) public void onMessage(ConsumerRecordString, String record, Acknowledgment ack) { try { OrderMessage message JSON.parseObject(record.value(), OrderMessage.class); // 1. 校驗(yàn)本地流水表是否已存在 // 2. 本地事務(wù)創(chuàng)建訂單、扣減數(shù)據(jù)庫庫存、更新流水狀態(tài) // 3. 假如流程成功則提交 offset ack.acknowledge(); } catch (Exception e) { // 記錄錯誤由對賬任務(wù)補(bǔ)償不要在這里無限重試 log.error(consume order message failed, e); } } }到這里一個最小鏈路就通了用戶調(diào)用秒殺接口 - Redis Lua 扣庫存 - Kafka 發(fā)消息 - 消費(fèi)者落庫。你可以用 Postman 或?qū)憘€ Jmeter 腳本模擬并發(fā)請求觀察 Redis 庫存不會變負(fù)數(shù)、數(shù)據(jù)庫訂單數(shù)不超過庫存數(shù)。5.3 壓測與監(jiān)控用實(shí)際數(shù)據(jù)驗(yàn)證方案Demo 寫完后要壓測。我用 JMeter 開 1000 線程循環(huán) 10 次觀察三個指標(biāo)Redis 的 QPS、Kafka 的消費(fèi) lag、數(shù)據(jù)庫的活躍連接數(shù)。壓測前先預(yù)熱否則第一次請求會大量落到數(shù)據(jù)庫。壓測中重點(diǎn)看 Redis 的info commandstats里 lua 腳本的平均耗時如果在 1ms 以下說明原子扣減還有余量。監(jiān)控上Spring Boot 可以接 Spring Boot Admin 或者 Micrometer Prometheus。如果你只是本地驗(yàn)證最簡單的就是直接看 Kafka 消費(fèi)組的 lag。命令如下kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group seckill-order-grouplag 為 0 說明消費(fèi)速度跟得上。如果 lag 持續(xù)增大優(yōu)先查消費(fèi)者日志里的 rebalance 記錄以及數(shù)據(jù)庫慢查詢?nèi)罩?。這個順序我壓測時用過幾十次不會錯。6. 踩坑實(shí)錄與個人心得6.1 線上坑 TOP5把我在真實(shí)秒殺項(xiàng)目里踩過的、也是面試官最喜歡問的坑整理成一張表方便你自查?？蝇F(xiàn)象根因解法Redis 庫存為負(fù)超賣判斷和扣減不是原子的Lua 腳本合并鎖被誤刪并發(fā)覆蓋釋放時沒有校驗(yàn)持有者釋放前用 Lua 比較 value消息丟失用戶搶到無訂單消費(fèi)者 offset 自動提交或生產(chǎn)者未確認(rèn)acksall 手動提交消費(fèi)順序錯亂同一用戶訂單亂序多線程消費(fèi)且沒有分區(qū)策略用用戶ID做 key固定分區(qū)消息體積超限發(fā)送失敗消息體塞入大字段只傳必要字段或調(diào)大 max.message.bytes第一行那個坑我印象最深。早期用 Redis 的get和decrby兩條命令來判斷庫存高并發(fā)下 A 請求讀到庫存 1B 請求也讀到庫存 1兩個都執(zhí)行 decrby庫存變成 -1。這就是典型的“非原子操作導(dǎo)致超賣”。后來換成 Lua 腳本再也沒出現(xiàn)過。面試現(xiàn)場你如果能主動講出這個演化過程會讓面試官有共鳴。第二行的鎖誤刪也很經(jīng)典。值用 UUID 后釋放鎖前必須用 Lua 判斷 value 再刪除。但還有一個更隱蔽的坑如果業(yè)務(wù)只加鎖不加續(xù)期代碼執(zhí)行超過鎖過期時間即使加了 UUID 也可能被誤刪。所以要么用 Redisson要么業(yè)務(wù)方法里盡量縮短鎖內(nèi)耗時。其實(shí)這些坑背后有個共同規(guī)律分布式場景下的每個判斷和操作都要優(yōu)先考慮是不是原子的、會不會因?yàn)榫W(wǎng)絡(luò)或宕機(jī)產(chǎn)生中間狀態(tài)。這個思維方式比背具體命令更重要。6.2 給新人的建議從 Demo 到項(xiàng)目實(shí)戰(zhàn)如果你現(xiàn)在還在學(xué)習(xí)階段我的建議是把 Demo 跑通之后再自己動手改造成一個完整的小項(xiàng)目增加商品活動表、把庫存預(yù)熱做成定時任務(wù)、給訂單消費(fèi)加上本地消息表和定時對賬然后用壓測驗(yàn)證超賣和消息積壓問題。這樣再去看大廠面經(jīng)就不會覺得“這只存在于面試官嘴里”了。有人說秒殺系統(tǒng)是面試造火箭、工作擰螺絲但我覺得秒殺場景是極少數(shù)能在一套系統(tǒng)里同時訓(xùn)練高并發(fā)、一致性和高可用的實(shí)戰(zhàn)場景。你把這些思路吃透再去面對日常的接口性能優(yōu)化、緩存治理和消息隊(duì)列問題思維層次會完全不一樣。最后說一個我壓箱底的小技巧秒殺活動開始前提前把商品庫存和活動信息預(yù)熱到 Redis并做一次小規(guī)模壓測別等線上流量真的涌進(jìn)來了才排查問題。還有所有秒殺相關(guān)操作都要加接口冪等和用戶級別限流不然腳本一刷你的活動就沒意義了。這些聽起來都是小事但線上的大事故往往就敗在這些小細(xì)節(jié)上。