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