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