Java 面試實(shí)錄Spring Boot Kafka Redis Spring Security AI 的大廠拷打現(xiàn)場\n場景互聯(lián)網(wǎng)大廠 Java 求職面試\n人物嚴(yán)肅面試官、搞笑水貨程序員燕雙非\n\n第一輪電商增長與高并發(fā)下單\n面試官我們先從一個(gè)電商秒殺場景開始。你用 Spring Boot 做下單接口時(shí)如何避免接口被刷爆\n燕雙非這個(gè)簡單先加限流再加 Redis 緩存必要時(shí)把庫存提前預(yù)熱到本地緩存里。Spring Boot 里我一般會(huì)配合攔截器或者網(wǎng)關(guān)做基礎(chǔ)防護(hù)。\n面試官回答得還行。那如果要在高并發(fā)下保證庫存不超賣你會(huì)怎么設(shè)計(jì)\n燕雙非嗯……可以先把庫存放 Redis用原子操作扣減數(shù)據(jù)庫再異步落庫。至于一致性嘛反正最后總會(huì)對(duì)上的大概吧。\n面試官你這個(gè)“大概”有點(diǎn)危險(xiǎn)。那消息隊(duì)列在這里怎么用\n燕雙非我會(huì)把下單請(qǐng)求先寫入 Kafka后面的訂單服務(wù)異步消費(fèi)。這樣削峰填谷前臺(tái)先返回“搶購成功待確認(rèn)”。\n面試官可以至少方向是對(duì)的。那你會(huì)如何處理 Kafka 消息重復(fù)消費(fèi)\n燕雙非……加個(gè)唯一訂單號(hào)消費(fèi)端做冪等校驗(yàn)。比如 Redis 記一下處理狀態(tài)或者數(shù)據(jù)庫訂單表加唯一索引。\n\n第二輪支付與風(fēng)控鏈路\n面試官現(xiàn)在訂單已經(jīng)創(chuàng)建成功進(jìn)入支付環(huán)節(jié)。Spring Security 在這個(gè)場景里怎么保護(hù)支付接口\n燕雙非登錄態(tài)要校驗(yàn)JWT 攜帶用戶身份接口鑒權(quán)交給 Spring Security。支付這種敏感接口還要加二次校驗(yàn)比如短信驗(yàn)證碼或者風(fēng)控令牌。\n面試官如果第三方支付回調(diào)來了你怎么防止偽造請(qǐng)求\n燕雙非驗(yàn)簽啊檢查簽名、時(shí)間戳、隨機(jī)串確認(rèn)是支付平臺(tái)發(fā)來的。要是再嚴(yán)一點(diǎn)可以把回調(diào) IP 白名單也加上。\n面試官回調(diào)處理失敗時(shí)如何保證賬務(wù)最終一致\n燕雙非可以用本地事務(wù)先記一條待處理流水然后再發(fā)消息給 Kafka。消費(fèi)端更新訂單和賬單狀態(tài)失敗就重試。還可以配合 Outbox 模式避免“數(shù)據(jù)庫寫成功、消息沒發(fā)出去”的尷尬。\n面試官不錯(cuò)。那你知道 Micrometer 在支付鏈路里有什么價(jià)值嗎\n燕雙非可以埋點(diǎn)統(tǒng)計(jì)接口耗時(shí)、成功率、異常率再接 Prometheus 和 Grafana 看板。這樣支付超時(shí)、Kafka 堆積、Redis 命中率下降都能更早發(fā)現(xiàn)。\n面試官這個(gè)回答比剛才靠譜。那如果風(fēng)控要求實(shí)時(shí)識(shí)別異常下單你會(huì)怎么結(jié)合 AI 能力\n燕雙非可以把用戶行為、設(shè)備指紋、歷史訂單特征做向量化再做語義檢索或者規(guī)則增強(qiáng)如果接 Spring AI 和 RAG把風(fēng)控知識(shí)庫、歷史案例接入讓模型輔助判斷風(fēng)險(xiǎn)等級(jí)。\n\n第三輪企業(yè)協(xié)同與智能客服\n面試官最后一個(gè)場景我們做企業(yè)協(xié)同 SaaS用戶會(huì)上傳大量合同和工單。你會(huì)怎么設(shè)計(jì)文檔問答系統(tǒng)\n燕雙非先文檔加載再切分文本做 Embedding存到向量數(shù)據(jù)庫里比如 Milvus 或 Redis。查詢時(shí)做語義檢索召回相關(guān)片段再交給大模型生成答案。\n面試官你提到了檢索。那如果企業(yè)客戶要求“不能胡說八道”你怎么控制 AI 幻覺\n燕雙非要盡量走 Agentic RAG答案必須基于檢索到的企業(yè)文檔提示詞里要求引用來源召回不足就直接說“不確定”。另外可以限制工具調(diào)用范圍避免模型瞎編。\n面試官如果客服系統(tǒng)還要支持實(shí)時(shí)消息你會(huì)考慮什么技術(shù)\n燕雙非可以用 WebSocket 做在線會(huì)話消息后端再接 Kafka 異步處理工單流轉(zhuǎn)。會(huì)話內(nèi)存可以記錄上下文方便多輪追問。\n面試官再補(bǔ)一個(gè)問題你如何把這一套系統(tǒng)做成可觀測、可擴(kuò)展的服務(wù)\n燕雙非服務(wù)層用 Spring Boot接口層加 OpenAPI監(jiān)控用 Micrometer Prometheus Grafana日志用 SLF4J 配合 Logback。容器化后上 Kubernetes配合健康檢查和彈性擴(kuò)縮容。AI 服務(wù)和業(yè)務(wù)服務(wù)拆開復(fù)雜工作流交給獨(dú)立編排層。\n面試官行今天先到這吧。你回去等通知。\n\n題目詳解\n1. 如何在 Spring Boot 電商秒殺場景中防止接口被刷爆\n高并發(fā)場景下入口保護(hù)通常分為網(wǎng)關(guān)層、應(yīng)用層、緩存層三道防線。網(wǎng)關(guān)層可做 IP 限流、用戶限流和黑名單攔截應(yīng)用層使用令牌桶、漏桶或滑動(dòng)窗口限流緩存層可將熱點(diǎn)商品信息、庫存、活動(dòng)配置提前緩存減少數(shù)據(jù)庫壓力。實(shí)際業(yè)務(wù)中通常會(huì)結(jié)合 Nginx、Gateway 或 Sentinel 一類組件做統(tǒng)一治理。\n2. 如何避免庫存超賣\n核心思想是讓“扣庫存”盡可能原子化。常見方案有Redis 原子扣減庫存、數(shù)據(jù)庫樂觀鎖扣減庫存、消息隊(duì)列異步下單后落庫。Redis 方案適合高并發(fā)搶購但最終仍需與數(shù)據(jù)庫對(duì)賬數(shù)據(jù)庫方案更穩(wěn)妥但吞吐較低。生產(chǎn)中常采用“Redis 預(yù)扣減 MQ 異步下單 數(shù)據(jù)庫最終確認(rèn)”的組合方案并通過冪等鍵、唯一索引、狀態(tài)機(jī)保證一致性。\n3. Kafka 在下單鏈路中的作用是什么\nKafka 的價(jià)值在于削峰填谷、異步解耦和擴(kuò)展吞吐。下單請(qǐng)求先進(jìn)入消息隊(duì)列訂單服務(wù)異步消費(fèi)后寫庫、扣減庫存、發(fā)通知。這樣前臺(tái)接口響應(yīng)更快后端也可按消費(fèi)能力平滑處理請(qǐng)求。需要注意消費(fèi)者冪等、消息重試、死信處理和分區(qū)順序性避免重復(fù)下單和狀態(tài)錯(cuò)亂。\n4. 如何處理 Kafka 重復(fù)消費(fèi)\n