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