Java 面試實錄Spring Boot Kafka Redis RAG 在電商大廠場景中的 3 輪攻防面試場景互聯(lián)網(wǎng)大廠電商業(yè)務(wù)線候選人燕雙非。面試官神情嚴肅手里翻著簡歷。面試官我們從電商高并發(fā)場景開始先聊基礎(chǔ)再聊業(yè)務(wù)落地最后聊你對 AI 能力的理解。第一輪電商下單鏈路與基礎(chǔ)架構(gòu)問題 1如果讓你設(shè)計一個秒殺下單接口Spring Boot 里你會怎么做限流和冪等燕雙非限流我會先用網(wǎng)關(guān)做像基于令牌桶或者漏桶的思路冪等的話前端提交一次訂單后后端可以通過唯一請求號配合 Redis 去重防止重復(fù)提交。面試官這個方向是對的。你至少知道限流前置和冪等控制的位置。問題 2庫存扣減你會放在 MySQL 里直接扣還是先走 Redis為什么燕雙非我會先用 Redis 預(yù)扣庫存避免數(shù)據(jù)庫扛不住真正落庫時再做校驗。數(shù)據(jù)庫直接扣也行但高峰期可能壓力很大。面試官回答還算穩(wěn)知道把熱點壓力從數(shù)據(jù)庫前移。問題 3訂單創(chuàng)建后要發(fā)消息通知庫存、營銷、物流你會怎么選消息隊列燕雙非Kafka 比較適合這種高吞吐異步解耦場景。訂單服務(wù)發(fā)出事件庫存、營銷各自消費彼此不阻塞。面試官不錯已經(jīng)開始考慮事件驅(qū)動了。第二輪支付、風控與可觀測性問題 1如果支付回調(diào)重復(fù)到達如何保證只處理一次燕雙非可以用數(shù)據(jù)庫唯一鍵約束加狀態(tài)機回調(diào)接口先查訂單狀態(tài)已處理就直接返回成功另外也可以結(jié)合 Redis 做短期冪等鎖。面試官比剛才更完整了既考慮了數(shù)據(jù)庫約束也考慮了緩存層。問題 2支付鏈路出問題后怎么快速定位是接口慢、MQ 堆積還是數(shù)據(jù)庫抖動燕雙非我會看 Prometheus 和 Grafana 的指標比如接口耗時、QPS、錯誤率再看 Kafka 積壓、Redis 命中率、數(shù)據(jù)庫連接池情況。日志用 ELK 或 Logback 配合 traceId 串起來。面試官很好已經(jīng)具備基本的可觀測性意識了。問題 3你知道 Spring Security 在支付系統(tǒng)里怎么做權(quán)限控制嗎燕雙非嗯……就是登錄后校驗角色吧敏感接口加個權(quán)限注解JWT 里放用戶信息網(wǎng)關(guān)統(tǒng)一驗簽。面試官思路可以但細節(jié)還不夠扎實后面要繼續(xù)補。問題 4如果風控系統(tǒng)要在下單時實時攔截異常用戶你會怎么接入燕雙非可以在訂單服務(wù)里同步調(diào)用風控服務(wù)或者先做一些本地規(guī)則預(yù)判再把結(jié)果發(fā)給風控中心復(fù)雜一點的話就走微服務(wù)鏈路和降級策略。面試官好至少知道同步攔截和異步畫像可以結(jié)合使用。第三輪AI 推薦與智能客服問題 1現(xiàn)在業(yè)務(wù)想做一個“訂單助手”支持自然語言查訂單、查退款你會怎么設(shè)計燕雙非我會考慮 Spring AI 之類的能力把用戶問題做意圖識別再去調(diào)用訂單查詢、退款查詢這些工具接口如果是知識類問題可以接 RAG從文檔庫里檢索答案。面試官這回答就比較像樣了已經(jīng)能把工具調(diào)用和檢索增強結(jié)合起來。問題 2RAG 為什么比直接把所有文檔喂給大模型更適合企業(yè)場景燕雙非因為文檔太多太大直接塞進去成本高、上下文也放不下。RAG 先做向量化和語義檢索只把相關(guān)片段拿出來給模型效率更高也更容易控制幻覺。面試官說得不錯方向?qū)σ呀?jīng)知道召回和上下文控制的價值。問題 3如果客服要支持多輪對話還要記住用戶剛才問過什么你怎么做燕雙非會給每個會話維護聊天記憶保存歷史問題和關(guān)鍵狀態(tài)如果要復(fù)雜一點還可以把工具執(zhí)行結(jié)果和中間狀態(tài)一起存起來避免每輪都重新計算。面試官可以知道會話內(nèi)存和狀態(tài)保持的重要性。問題 4最后一個問題AI 幻覺怎么處理燕雙非呃……我覺得可以多讓模型“認真一點”然后把提示詞寫清楚必要時加人工審核再配合檢索和規(guī)則校驗應(yīng)該就能好很多。面試官行先到這兒吧。你的基礎(chǔ)有一些但對復(fù)雜鏈路和 AI 落地細節(jié)還需要繼續(xù)加強。你先回去等通知吧。問題詳解與業(yè)務(wù)場景剖析1. 秒殺接口的限流與冪等在電商秒殺中流量會在短時間內(nèi)集中爆發(fā)。限流通常放在網(wǎng)關(guān)層或接口入口層常見方式包括令牌桶、漏桶、滑動窗口。Spring Boot 應(yīng)用中可以結(jié)合 Gateway、Resilience4j 或自定義攔截器實現(xiàn)。冪等的核心是“同一請求只處理一次”。實踐中通常使用唯一請求號 Redis 去重數(shù)據(jù)庫唯一索引約束狀態(tài)機控制訂單流轉(zhuǎn)這樣能防止重復(fù)點擊、重試、網(wǎng)絡(luò)抖動帶來的重復(fù)下單。2. 庫存預(yù)扣與最終落庫高并發(fā)下直接操作數(shù)據(jù)庫容易成為瓶頸因此常見方案是 Redis 預(yù)扣庫存先在緩存層快速判斷是否可賣再異步或同步落庫。這種方式的關(guān)鍵在于一致性控制Redis 和數(shù)據(jù)庫之間不能只靠“感覺一致”要有補償、對賬、消息重試等機制。庫存扣減往往配合消息隊列保證訂單、庫存、營銷之間松耦合。3. Kafka 在訂單鏈路中的作用 Java 面試實錄：Spring Boot + Kafka + Redis + RAG 在電商大廠場景中的 3 輪攻防
Java 面試實錄Spring Boot Kafka Redis RAG 在電商大廠場景中的 3 輪攻防面試場景互聯(lián)網(wǎng)大廠電商業(yè)務(wù)線候選人燕雙非。面試官神情嚴肅手里翻著簡歷。面試官我們從電商高并發(fā)場景開始先聊基礎(chǔ)再聊業(yè)務(wù)落地最后聊你對 AI 能力的理解。第一輪電商下單鏈路與基礎(chǔ)架構(gòu)問題 1如果讓你設(shè)計一個秒殺下單接口Spring Boot 里你會怎么做限流和冪等燕雙非限流我會先用網(wǎng)關(guān)做像基于令牌桶或者漏桶的思路冪等的話前端提交一次訂單后后端可以通過唯一請求號配合 Redis 去重防止重復(fù)提交。面試官這個方向是對的。你至少知道限流前置和冪等控制的位置。問題 2庫存扣減你會放在 MySQL 里直接扣還是先走 Redis為什么燕雙非我會先用 Redis 預(yù)扣庫存避免數(shù)據(jù)庫扛不住真正落庫時再做校驗。數(shù)據(jù)庫直接扣也行但高峰期可能壓力很大。面試官回答還算穩(wěn)知道把熱點壓力從數(shù)據(jù)庫前移。問題 3訂單創(chuàng)建后要發(fā)消息通知庫存、營銷、物流你會怎么選消息隊列燕雙非Kafka 比較適合這種高吞吐異步解耦場景。訂單服務(wù)發(fā)出事件庫存、營銷各自消費彼此不阻塞。面試官不錯已經(jīng)開始考慮事件驅(qū)動了。第二輪支付、風控與可觀測性問題 1如果支付回調(diào)重復(fù)到達如何保證只處理一次燕雙非可以用數(shù)據(jù)庫唯一鍵約束加狀態(tài)機回調(diào)接口先查訂單狀態(tài)已處理就直接返回成功另外也可以結(jié)合 Redis 做短期冪等鎖。面試官比剛才更完整了既考慮了數(shù)據(jù)庫約束也考慮了緩存層。問題 2支付鏈路出問題后怎么快速定位是接口慢、MQ 堆積還是數(shù)據(jù)庫抖動燕雙非我會看 Prometheus 和 Grafana 的指標比如接口耗時、QPS、錯誤率再看 Kafka 積壓、Redis 命中率、數(shù)據(jù)庫連接池情況。日志用 ELK 或 Logback 配合 traceId 串起來。面試官很好已經(jīng)具備基本的可觀測性意識了。問題 3你知道 Spring Security 在支付系統(tǒng)里怎么做權(quán)限控制嗎燕雙非嗯……就是登錄后校驗角色吧敏感接口加個權(quán)限注解JWT 里放用戶信息網(wǎng)關(guān)統(tǒng)一驗簽。面試官思路可以但細節(jié)還不夠扎實后面要繼續(xù)補。問題 4如果風控系統(tǒng)要在下單時實時攔截異常用戶你會怎么接入燕雙非可以在訂單服務(wù)里同步調(diào)用風控服務(wù)或者先做一些本地規(guī)則預(yù)判再把結(jié)果發(fā)給風控中心復(fù)雜一點的話就走微服務(wù)鏈路和降級策略。面試官好至少知道同步攔截和異步畫像可以結(jié)合使用。第三輪AI 推薦與智能客服問題 1現(xiàn)在業(yè)務(wù)想做一個“訂單助手”支持自然語言查訂單、查退款你會怎么設(shè)計燕雙非我會考慮 Spring AI 之類的能力把用戶問題做意圖識別再去調(diào)用訂單查詢、退款查詢這些工具接口如果是知識類問題可以接 RAG從文檔庫里檢索答案。面試官這回答就比較像樣了已經(jīng)能把工具調(diào)用和檢索增強結(jié)合起來。問題 2RAG 為什么比直接把所有文檔喂給大模型更適合企業(yè)場景燕雙非因為文檔太多太大直接塞進去成本高、上下文也放不下。RAG 先做向量化和語義檢索只把相關(guān)片段拿出來給模型效率更高也更容易控制幻覺。面試官說得不錯方向?qū)σ呀?jīng)知道召回和上下文控制的價值。問題 3如果客服要支持多輪對話還要記住用戶剛才問過什么你怎么做燕雙非會給每個會話維護聊天記憶保存歷史問題和關(guān)鍵狀態(tài)如果要復(fù)雜一點還可以把工具執(zhí)行結(jié)果和中間狀態(tài)一起存起來避免每輪都重新計算。面試官可以知道會話內(nèi)存和狀態(tài)保持的重要性。問題 4最后一個問題AI 幻覺怎么處理燕雙非呃……我覺得可以多讓模型“認真一點”然后把提示詞寫清楚必要時加人工審核再配合檢索和規(guī)則校驗應(yīng)該就能好很多。面試官行先到這兒吧。你的基礎(chǔ)有一些但對復(fù)雜鏈路和 AI 落地細節(jié)還需要繼續(xù)加強。你先回去等通知吧。問題詳解與業(yè)務(wù)場景剖析1. 秒殺接口的限流與冪等在電商秒殺中流量會在短時間內(nèi)集中爆發(fā)。限流通常放在網(wǎng)關(guān)層或接口入口層常見方式包括令牌桶、漏桶、滑動窗口。Spring Boot 應(yīng)用中可以結(jié)合 Gateway、Resilience4j 或自定義攔截器實現(xiàn)。冪等的核心是“同一請求只處理一次”。實踐中通常使用唯一請求號 Redis 去重數(shù)據(jù)庫唯一索引約束狀態(tài)機控制訂單流轉(zhuǎn)這樣能防止重復(fù)點擊、重試、網(wǎng)絡(luò)抖動帶來的重復(fù)下單。2. 庫存預(yù)扣與最終落庫高并發(fā)下直接操作數(shù)據(jù)庫容易成為瓶頸因此常見方案是 Redis 預(yù)扣庫存先在緩存層快速判斷是否可賣再異步或同步落庫。這種方式的關(guān)鍵在于一致性控制Redis 和數(shù)據(jù)庫之間不能只靠“感覺一致”要有補償、對賬、消息重試等機制。庫存扣減往往配合消息隊列保證訂單、庫存、營銷之間松耦合。3. Kafka 在訂單鏈路中的作用