：會(huì)話緩存優(yōu)先的多級查詢策略與DeepSeek流式接入)
簡介這份資源是一套基于SpringBoot與Vue.js前后端分離架構(gòu)的AI智能客服系統(tǒng)完整源碼面向具備Java與前端基礎(chǔ)的開發(fā)者、課程設(shè)計(jì)或畢業(yè)設(shè)計(jì)人群解決自然語言對話與高并發(fā)響應(yīng)場景下的系統(tǒng)搭建問題。壓縮包共63個(gè)文件、約23.76MB以43個(gè)Java源文件為核心輔以SQL建庫腳本、properties配置、bat與cmd啟動(dòng)腳本、html頁面及md說明文檔并附運(yùn)行錄屏mp4與說明文檔覆蓋后端服務(wù)、前端界面與數(shù)據(jù)庫全鏈路。系統(tǒng)集成DeepSeek開源大模型API實(shí)現(xiàn)上下文感知對話與流式輸出并采用多級緩存查詢策略優(yōu)先命中會(huì)話緩存、未命中再匹配數(shù)據(jù)庫以降低負(fù)載、縮短等待。前端借助Vue組件化與響應(yīng)式設(shè)計(jì)提供動(dòng)態(tài)交互界面后端依托SpringBoot自動(dòng)配置與獨(dú)立運(yùn)行特性簡化搭建維護(hù)。目前已有124人學(xué)習(xí)適合對照源碼理解架構(gòu)設(shè)計(jì)、接口組織與緩存優(yōu)化思路。1. 前后端分離的 AI 客服系統(tǒng)為什么“會(huì)話緩存優(yōu)先”比模型本身更值得先做很多團(tuán)隊(duì)做 AI 客服第一反應(yīng)是選模型、調(diào)提示詞、比參數(shù)結(jié)果上線三天就被兩件事打臉一是每次請求都打到模型 API賬單和延遲一起飆升二是用戶刷新頁面上一輪的上下文全丟了客服像失憶一樣反復(fù)問“請問您遇到了什么問題”。標(biāo)題里這套方案的核心其實(shí)不在模型而在“多級緩存查詢策略優(yōu)先訪問會(huì)話緩存再匹配”這句話——它決定了你的系統(tǒng)是能扛住真實(shí)流量還是只能活在演示視頻里。這套架構(gòu)適合誰適合已經(jīng)有一個(gè)業(yè)務(wù)后臺(tái)、想給現(xiàn)有系統(tǒng)加一個(gè)能記住上下文、能流式吐字、成本可控的智能客服入口的團(tuán)隊(duì)。前端用 Vue.js 做對話界面后端用 SpringBoot 做編排層模型側(cè)接 DeepSeek 的 OpenAI 兼容接口中間用 Redis 做會(huì)話緩存再往下才是向量匹配或關(guān)鍵詞匹配。整條鏈路里模型只是最后一環(huán)前面每一環(huán)都在決定“要不要真的調(diào)用模型”。下面按落地順序拆開講。2. 會(huì)話緩存優(yōu)先的多級查詢鏈路從 Redis 到向量庫再到模型2.1 為什么第一級必須是會(huì)話緩存而不是向量庫用戶問“剛才那個(gè)訂單還能改地址嗎”這句話本身沒有多少語義檢索價(jià)值它的答案完全依賴上一輪對話里提到的訂單號。如果你先走向量庫會(huì)召回一堆“改地址”“訂單修改”的通用文檔反而把真正的上下文擠掉。所以第一級查詢應(yīng)該是按 sessionId 直接取 Redis 里的會(huì)話歷史命中就直接拼進(jìn) prompt不命中才走第二級。第二級是業(yè)務(wù)知識(shí)匹配。常見做法是用問題文本去查向量庫或 ES拿到 topK 片段。第三級才是兜底如果前兩級都沒拿到有效內(nèi)容或者用戶明確要求“轉(zhuǎn)人工”“找客服”就直接返回預(yù)設(shè)話術(shù)不調(diào)用模型。這個(gè)順序能砍掉大量無效模型調(diào)用我一般會(huì)把第一級緩存的 TTL 設(shè)成 30 分鐘滑動(dòng)續(xù)期用戶活躍就一直在。2.2 SpringBoot 側(cè)的三級查詢骨架代碼// ConversationService.java public ChatResponse handle(String sessionId, String userInput) { // 第一級會(huì)話緩存直接拿最近 N 輪 ListMessage history redisTemplate.opsForList() .range(chat:session: sessionId, -10, -1); if (history ! null !history.isEmpty()) { // 命中緩存續(xù)期 30 分鐘 redisTemplate.expire(chat:session: sessionId, 30, TimeUnit.MINUTES); } // 第二級知識(shí)匹配只有緩存里沒有明確答案時(shí)才查 ListString knowledge knowledgeRetriever.search(userInput, 3); // 第三級拼 prompt決定是否調(diào)用模型 String prompt promptBuilder.build(history, knowledge, userInput); if (prompt null) { return ChatResponse.fallback(請稍等正在為您轉(zhuǎn)接人工客服); } return deepSeekClient.streamChat(prompt, sessionId); }這段代碼的關(guān)鍵在range(-10, -1)只取最近 10 條消息不是全部歷史。很多新手會(huì)把整個(gè)會(huì)話列表塞進(jìn) prompt結(jié)果 token 爆炸、模型開始胡言亂語。10 這個(gè)數(shù)字可以調(diào)但一般不超過 20。expire續(xù)期是滑動(dòng)窗口用戶每說一句就續(xù) 30 分鐘避免聊到一半緩存過期導(dǎo)致上下文斷裂。2.3 DeepSeek API 的流式輸出怎么接DeepSeek 提供 OpenAI 兼容的/chat/completions接口開stream: true就能拿到 SSE 流。SpringBoot 側(cè)用 WebClient 或 OkHttp 的流式讀取逐塊轉(zhuǎn)發(fā)給前端。注意不要用 RestTemplate它會(huì)把整個(gè)響應(yīng)緩沖完再返回流式就廢了。// DeepSeekClient.java public FluxString streamChat(String prompt, String sessionId) { return webClient.post() .uri(/chat/completions) .header(Authorization, Bearer apiKey) .contentType(MediaType.APPLICATION_JSON) .bodyValue(Map.of( model, deepseek-chat, stream, true, messages, List.of(Map.of(role, user, content, prompt)) )) .retrieve() .bodyToFlux(String.class) .filter(line - line.startsWith(data: ) !line.contains([DONE])) .map(line - line.substring(6)) .map(this::extractDelta); }extractDelta負(fù)責(zé)從 JSON 里取choices[0].delta.content。這里有個(gè)坑SSE 返回的每一行不一定都是完整 JSON偶爾會(huì)有空行或心跳過濾條件要寫嚴(yán)。另外[DONE]標(biāo)記必須處理否則前端會(huì)一直等。2.4 Vue.js 前端怎么消費(fèi)流式響應(yīng)前端不要用 axios它默認(rèn)不支持流式讀取。用原生fetch加ReadableStream逐塊解析。// ChatStream.js async function sendMessage(sessionId, text, onChunk) { const resp await fetch(/api/chat/stream, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ sessionId, text }) }); const reader resp.body.getReader(); const decoder new TextDecoder(utf-8); let buffer ; while (true) { const { done, value } await reader.read(); if (done) break; buffer decoder.decode(value, { stream: true }); const lines buffer.split(\n); buffer lines.pop(); // 最后一行可能不完整留到下次 for (const line of lines) { if (line.startsWith(data: )) { onChunk(line.slice(6)); } } } }buffer的處理是流式解析的經(jīng)典坑TCP 分片不保證按行到達(dá)必須把最后一段不完整的行留到下一次拼接。很多前端 demo 直接split(\n)然后全量處理遇到長回復(fù)就會(huì)丟字或報(bào) JSON 解析錯(cuò)誤。3. 會(huì)話緩存與上下文感知的工程細(xì)節(jié)TTL、截?cái)嗪筒l(fā)寫3.1 Redis 會(huì)話結(jié)構(gòu)怎么設(shè)計(jì)才不翻車常見做法是用 List 存消息LPUSH新消息LTRIM保留最近 20 條。但 List 有個(gè)問題你要取最近 10 條得用LRANGE -10 -1順序是反的還得在代碼里反轉(zhuǎn)。更穩(wěn)的是用 ZSetscore 用時(shí)間戳ZREVRANGE取最近 N 條天然有序。# 寫入一條用戶消息 ZADD chat:session:{sessionId} {timestamp} {role:user,content:...} # 只保留最近 20 條防止無限增長 ZREMRANGEBYRANK chat:session:{sessionId} 0 -21 # 取最近 10 條 ZREVRANGE chat:session:{sessionId} 0 9 WITHSCORESZREMRANGEBYRANK的-21表示保留最后 20 個(gè)成員前面的全刪。這個(gè)操作要放在每次寫入之后否則會(huì)話越長內(nèi)存越漲。TTL 單獨(dú)設(shè)EXPIRE和 ZSet 長度控制是兩件事。3.2 上下文截?cái)嗟娜N策略和選擇依據(jù)不是所有歷史都值得塞進(jìn) prompt。我一般按優(yōu)先級截?cái)嘧罱?3 輪完整保留第 4 到第 10 輪只保留用戶問題不保留模型回復(fù)更早的直接丟棄。原因是模型回復(fù)通常很長占 token 大頭而用戶問題才是理解意圖的關(guān)鍵。另一種做法是按 token 數(shù)截?cái)嘤?tiktoken 之類的庫估算超過 3000 token 就從最老的開始刪。這種方式更精確但多一次計(jì)算開銷。如果你們的對話普遍短用輪數(shù)截?cái)嗑蛪蛄巳绻脩艚?jīng)常粘貼大段文本必須上 token 截?cái)唷?.3 并發(fā)寫同一會(huì)話的鎖問題同一個(gè)用戶開兩個(gè)標(biāo)簽頁同時(shí)發(fā)消息兩個(gè)請求同時(shí)讀 Redis、同時(shí)調(diào)模型、同時(shí)寫回后寫的會(huì)覆蓋先寫的導(dǎo)致上下文錯(cuò)亂。解決辦法是在 sessionId 維度加分布式鎖用 Redis 的SETNX實(shí)現(xiàn)鎖超時(shí)設(shè) 5 秒。String lockKey lock:session: sessionId; Boolean locked redisTemplate.opsForValue() .setIfAbsent(lockKey, 1, 5, TimeUnit.SECONDS); if (Boolean.FALSE.equals(locked)) { return ChatResponse.fallback(您發(fā)送太快了請稍后再試); } try { // 讀緩存、調(diào)模型、寫緩存 } finally { redisTemplate.delete(lockKey); }鎖的粒度是 sessionId不是全局所以不同用戶之間不影響。5 秒超時(shí)是防止某個(gè)請求卡死導(dǎo)致鎖一直不釋放。這個(gè)邏輯放在 Controller 層還是 Service 層都行但一定要在 finally 里刪鎖。4. 避坑與排查流式輸出、緩存穿透和模型超時(shí)的真實(shí)記錄4.1 現(xiàn)象前端收到一堆亂碼或 JSON 解析失敗原因通常是后端把 SSE 的data:前綴重復(fù)拼了或者前端把非 data 行也當(dāng)數(shù)據(jù)解析。解決方法是后端只返回data: {...}\n\n格式前端嚴(yán)格判斷startsWith(data: )并且對[DONE]單獨(dú)處理。另外注意響應(yīng)頭要設(shè)Content-Type: text/event-stream否則瀏覽器可能緩沖。4.2 現(xiàn)象Redis 里會(huì)話突然全沒了用戶反饋“機(jī)器人失憶”先查 TTL 是不是設(shè)太短再查是不是有代碼在寫的時(shí)候誤刪了 key。我遇到過一種情況ZREMRANGEBYRANK的 rank 參數(shù)寫成了正數(shù)結(jié)果每次寫入都把最新消息刪了。排查時(shí)用MONITOR命令看實(shí)際執(zhí)行的 Redis 指令比看代碼快。4.3 現(xiàn)象模型返回很慢用戶等 10 秒才看到第一個(gè)字DeepSeek 的流式接口首 token 延遲通常在 1 到 3 秒如果超過 5 秒先檢查你的 WebClient 是不是開了緩沖。另外 prompt 太長也會(huì)拖慢首 token把歷史截?cái)嗟?10 條以內(nèi)通常能明顯改善。如果還是慢考慮在等待模型時(shí)先返回一個(gè)“正在思考”的占位消息。4.4 現(xiàn)象緩存命中率很高但回答質(zhì)量反而下降這是因?yàn)榫彺胬锏臍v史太舊用戶已經(jīng)換了話題模型還在參考半小時(shí)前的對話。解決辦法是加一個(gè)話題切換檢測如果當(dāng)前問題和最近一條消息的相似度低于閾值就清空歷史重新開始。簡單做法是用編輯距離或關(guān)鍵詞重合度不需要上模型。5. 進(jìn)階技巧用緩存命中率反推系統(tǒng)健康度上線之后別只盯著模型準(zhǔn)確率先看三個(gè)數(shù)會(huì)話緩存命中率、知識(shí)匹配命中率、模型調(diào)用占比。健康系統(tǒng)的模型調(diào)用占比應(yīng)該低于 40%也就是說超過一半的請求在前兩級就被消化了。如果這個(gè)數(shù)高于 70%說明你的緩存策略沒起作用或者知識(shí)庫覆蓋太差。我一般會(huì)在 Redis 里額外記一個(gè)計(jì)數(shù)器每次請求走完三級鏈路后INCR對應(yīng)的 key然后用 Grafana 看趨勢。緩存命中率突然下降通常是 TTL 配置被改了或者某個(gè)版本的代碼把 sessionId 生成邏輯改了導(dǎo)致 key 對不上。這種問題不看監(jiān)控很難發(fā)現(xiàn)等用戶投訴就晚了。另一個(gè)技巧是給流式輸出加一個(gè)“首字超時(shí)”兜底如果 3 秒內(nèi)沒有收到第一個(gè) chunk就主動(dòng)斷開并返回預(yù)設(shè)話術(shù)同時(shí)記錄一條日志。這樣用戶不會(huì)干等你也能知道模型側(cè)是不是出了問題。這個(gè)邏輯用Flux.timeout()就能實(shí)現(xiàn)比在前端做超時(shí)更可靠。最后說個(gè)我自己的習(xí)慣每次改緩存策略之前先把 Redis 里的會(huì)話樣本導(dǎo)出 100 條跑一遍離線回放看新的截?cái)噙壿嫊?huì)不會(huì)把關(guān)鍵上下文丟掉。這個(gè)動(dòng)作花不了十分鐘但能避免上線后“機(jī)器人突然變傻”的血淚事故。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取 前后端分離AI客服系統(tǒng)：會(huì)話緩存優(yōu)先的多級查詢策略與DeepSeek流式接入
簡介這份資源是一套基于SpringBoot與Vue.js前后端分離架構(gòu)的AI智能客服系統(tǒng)完整源碼面向具備Java與前端基礎(chǔ)的開發(fā)者、課程設(shè)計(jì)或畢業(yè)設(shè)計(jì)人群解決自然語言對話與高并發(fā)響應(yīng)場景下的系統(tǒng)搭建問題。壓縮包共63個(gè)文件、約23.76MB以43個(gè)Java源文件為核心輔以SQL建庫腳本、properties配置、bat與cmd啟動(dòng)腳本、html頁面及md說明文檔并附運(yùn)行錄屏mp4與說明文檔覆蓋后端服務(wù)、前端界面與數(shù)據(jù)庫全鏈路。系統(tǒng)集成DeepSeek開源大模型API實(shí)現(xiàn)上下文感知對話與流式輸出并采用多級緩存查詢策略優(yōu)先命中會(huì)話緩存、未命中再匹配數(shù)據(jù)庫以降低負(fù)載、縮短等待。前端借助Vue組件化與響應(yīng)式設(shè)計(jì)提供動(dòng)態(tài)交互界面后端依托SpringBoot自動(dòng)配置與獨(dú)立運(yùn)行特性簡化搭建維護(hù)。目前已有124人學(xué)習(xí)適合對照源碼理解架構(gòu)設(shè)計(jì)、接口組織與緩存優(yōu)化思路。1. 前后端分離的 AI 客服系統(tǒng)為什么“會(huì)話緩存優(yōu)先”比模型本身更值得先做很多團(tuán)隊(duì)做 AI 客服第一反應(yīng)是選模型、調(diào)提示詞、比參數(shù)結(jié)果上線三天就被兩件事打臉一是每次請求都打到模型 API賬單和延遲一起飆升二是用戶刷新頁面上一輪的上下文全丟了客服像失憶一樣反復(fù)問“請問您遇到了什么問題”。標(biāo)題里這套方案的核心其實(shí)不在模型而在“多級緩存查詢策略優(yōu)先訪問會(huì)話緩存再匹配”這句話——它決定了你的系統(tǒng)是能扛住真實(shí)流量還是只能活在演示視頻里。這套架構(gòu)適合誰適合已經(jīng)有一個(gè)業(yè)務(wù)后臺(tái)、想給現(xiàn)有系統(tǒng)加一個(gè)能記住上下文、能流式吐字、成本可控的智能客服入口的團(tuán)隊(duì)。前端用 Vue.js 做對話界面后端用 SpringBoot 做編排層模型側(cè)接 DeepSeek 的 OpenAI 兼容接口中間用 Redis 做會(huì)話緩存再往下才是向量匹配或關(guān)鍵詞匹配。整條鏈路里模型只是最后一環(huán)前面每一環(huán)都在決定“要不要真的調(diào)用模型”。下面按落地順序拆開講。2. 會(huì)話緩存優(yōu)先的多級查詢鏈路從 Redis 到向量庫再到模型2.1 為什么第一級必須是會(huì)話緩存而不是向量庫用戶問“剛才那個(gè)訂單還能改地址嗎”這句話本身沒有多少語義檢索價(jià)值它的答案完全依賴上一輪對話里提到的訂單號。如果你先走向量庫會(huì)召回一堆“改地址”“訂單修改”的通用文檔反而把真正的上下文擠掉。所以第一級查詢應(yīng)該是按 sessionId 直接取 Redis 里的會(huì)話歷史命中就直接拼進(jìn) prompt不命中才走第二級。第二級是業(yè)務(wù)知識(shí)匹配。常見做法是用問題文本去查向量庫或 ES拿到 topK 片段。第三級才是兜底如果前兩級都沒拿到有效內(nèi)容或者用戶明確要求“轉(zhuǎn)人工”“找客服”就直接返回預(yù)設(shè)話術(shù)不調(diào)用模型。這個(gè)順序能砍掉大量無效模型調(diào)用我一般會(huì)把第一級緩存的 TTL 設(shè)成 30 分鐘滑動(dòng)續(xù)期用戶活躍就一直在。2.2 SpringBoot 側(cè)的三級查詢骨架代碼// ConversationService.java public ChatResponse handle(String sessionId, String userInput) { // 第一級會(huì)話緩存直接拿最近 N 輪 ListMessage history redisTemplate.opsForList() .range(chat:session: sessionId, -10, -1); if (history ! null !history.isEmpty()) { // 命中緩存續(xù)期 30 分鐘 redisTemplate.expire(chat:session: sessionId, 30, TimeUnit.MINUTES); } // 第二級知識(shí)匹配只有緩存里沒有明確答案時(shí)才查 ListString knowledge knowledgeRetriever.search(userInput, 3); // 第三級拼 prompt決定是否調(diào)用模型 String prompt promptBuilder.build(history, knowledge, userInput); if (prompt null) { return ChatResponse.fallback(請稍等正在為您轉(zhuǎn)接人工客服); } return deepSeekClient.streamChat(prompt, sessionId); }這段代碼的關(guān)鍵在range(-10, -1)只取最近 10 條消息不是全部歷史。很多新手會(huì)把整個(gè)會(huì)話列表塞進(jìn) prompt結(jié)果 token 爆炸、模型開始胡言亂語。10 這個(gè)數(shù)字可以調(diào)但一般不超過 20。expire續(xù)期是滑動(dòng)窗口用戶每說一句就續(xù) 30 分鐘避免聊到一半緩存過期導(dǎo)致上下文斷裂。2.3 DeepSeek API 的流式輸出怎么接DeepSeek 提供 OpenAI 兼容的/chat/completions接口開stream: true就能拿到 SSE 流。SpringBoot 側(cè)用 WebClient 或 OkHttp 的流式讀取逐塊轉(zhuǎn)發(fā)給前端。注意不要用 RestTemplate它會(huì)把整個(gè)響應(yīng)緩沖完再返回流式就廢了。// DeepSeekClient.java public FluxString streamChat(String prompt, String sessionId) { return webClient.post() .uri(/chat/completions) .header(Authorization, Bearer apiKey) .contentType(MediaType.APPLICATION_JSON) .bodyValue(Map.of( model, deepseek-chat, stream, true, messages, List.of(Map.of(role, user, content, prompt)) )) .retrieve() .bodyToFlux(String.class) .filter(line - line.startsWith(data: ) !line.contains([DONE])) .map(line - line.substring(6)) .map(this::extractDelta); }extractDelta負(fù)責(zé)從 JSON 里取choices[0].delta.content。這里有個(gè)坑SSE 返回的每一行不一定都是完整 JSON偶爾會(huì)有空行或心跳過濾條件要寫嚴(yán)。另外[DONE]標(biāo)記必須處理否則前端會(huì)一直等。2.4 Vue.js 前端怎么消費(fèi)流式響應(yīng)前端不要用 axios它默認(rèn)不支持流式讀取。用原生fetch加ReadableStream逐塊解析。// ChatStream.js async function sendMessage(sessionId, text, onChunk) { const resp await fetch(/api/chat/stream, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ sessionId, text }) }); const reader resp.body.getReader(); const decoder new TextDecoder(utf-8); let buffer ; while (true) { const { done, value } await reader.read(); if (done) break; buffer decoder.decode(value, { stream: true }); const lines buffer.split(\n); buffer lines.pop(); // 最后一行可能不完整留到下次 for (const line of lines) { if (line.startsWith(data: )) { onChunk(line.slice(6)); } } } }buffer的處理是流式解析的經(jīng)典坑TCP 分片不保證按行到達(dá)必須把最后一段不完整的行留到下一次拼接。很多前端 demo 直接split(\n)然后全量處理遇到長回復(fù)就會(huì)丟字或報(bào) JSON 解析錯(cuò)誤。3. 會(huì)話緩存與上下文感知的工程細(xì)節(jié)TTL、截?cái)嗪筒l(fā)寫3.1 Redis 會(huì)話結(jié)構(gòu)怎么設(shè)計(jì)才不翻車常見做法是用 List 存消息LPUSH新消息LTRIM保留最近 20 條。但 List 有個(gè)問題你要取最近 10 條得用LRANGE -10 -1順序是反的還得在代碼里反轉(zhuǎn)。更穩(wěn)的是用 ZSetscore 用時(shí)間戳ZREVRANGE取最近 N 條天然有序。# 寫入一條用戶消息 ZADD chat:session:{sessionId} {timestamp} {role:user,content:...} # 只保留最近 20 條防止無限增長 ZREMRANGEBYRANK chat:session:{sessionId} 0 -21 # 取最近 10 條 ZREVRANGE chat:session:{sessionId} 0 9 WITHSCORESZREMRANGEBYRANK的-21表示保留最后 20 個(gè)成員前面的全刪。這個(gè)操作要放在每次寫入之后否則會(huì)話越長內(nèi)存越漲。TTL 單獨(dú)設(shè)EXPIRE和 ZSet 長度控制是兩件事。3.2 上下文截?cái)嗟娜N策略和選擇依據(jù)不是所有歷史都值得塞進(jìn) prompt。我一般按優(yōu)先級截?cái)嘧罱?3 輪完整保留第 4 到第 10 輪只保留用戶問題不保留模型回復(fù)更早的直接丟棄。原因是模型回復(fù)通常很長占 token 大頭而用戶問題才是理解意圖的關(guān)鍵。另一種做法是按 token 數(shù)截?cái)嘤?tiktoken 之類的庫估算超過 3000 token 就從最老的開始刪。這種方式更精確但多一次計(jì)算開銷。如果你們的對話普遍短用輪數(shù)截?cái)嗑蛪蛄巳绻脩艚?jīng)常粘貼大段文本必須上 token 截?cái)唷?.3 并發(fā)寫同一會(huì)話的鎖問題同一個(gè)用戶開兩個(gè)標(biāo)簽頁同時(shí)發(fā)消息兩個(gè)請求同時(shí)讀 Redis、同時(shí)調(diào)模型、同時(shí)寫回后寫的會(huì)覆蓋先寫的導(dǎo)致上下文錯(cuò)亂。解決辦法是在 sessionId 維度加分布式鎖用 Redis 的SETNX實(shí)現(xiàn)鎖超時(shí)設(shè) 5 秒。String lockKey lock:session: sessionId; Boolean locked redisTemplate.opsForValue() .setIfAbsent(lockKey, 1, 5, TimeUnit.SECONDS); if (Boolean.FALSE.equals(locked)) { return ChatResponse.fallback(您發(fā)送太快了請稍后再試); } try { // 讀緩存、調(diào)模型、寫緩存 } finally { redisTemplate.delete(lockKey); }鎖的粒度是 sessionId不是全局所以不同用戶之間不影響。5 秒超時(shí)是防止某個(gè)請求卡死導(dǎo)致鎖一直不釋放。這個(gè)邏輯放在 Controller 層還是 Service 層都行但一定要在 finally 里刪鎖。4. 避坑與排查流式輸出、緩存穿透和模型超時(shí)的真實(shí)記錄4.1 現(xiàn)象前端收到一堆亂碼或 JSON 解析失敗原因通常是后端把 SSE 的data:前綴重復(fù)拼了或者前端把非 data 行也當(dāng)數(shù)據(jù)解析。解決方法是后端只返回data: {...}\n\n格式前端嚴(yán)格判斷startsWith(data: )并且對[DONE]單獨(dú)處理。另外注意響應(yīng)頭要設(shè)Content-Type: text/event-stream否則瀏覽器可能緩沖。4.2 現(xiàn)象Redis 里會(huì)話突然全沒了用戶反饋“機(jī)器人失憶”先查 TTL 是不是設(shè)太短再查是不是有代碼在寫的時(shí)候誤刪了 key。我遇到過一種情況ZREMRANGEBYRANK的 rank 參數(shù)寫成了正數(shù)結(jié)果每次寫入都把最新消息刪了。排查時(shí)用MONITOR命令看實(shí)際執(zhí)行的 Redis 指令比看代碼快。4.3 現(xiàn)象模型返回很慢用戶等 10 秒才看到第一個(gè)字DeepSeek 的流式接口首 token 延遲通常在 1 到 3 秒如果超過 5 秒先檢查你的 WebClient 是不是開了緩沖。另外 prompt 太長也會(huì)拖慢首 token把歷史截?cái)嗟?10 條以內(nèi)通常能明顯改善。如果還是慢考慮在等待模型時(shí)先返回一個(gè)“正在思考”的占位消息。4.4 現(xiàn)象緩存命中率很高但回答質(zhì)量反而下降這是因?yàn)榫彺胬锏臍v史太舊用戶已經(jīng)換了話題模型還在參考半小時(shí)前的對話。解決辦法是加一個(gè)話題切換檢測如果當(dāng)前問題和最近一條消息的相似度低于閾值就清空歷史重新開始。簡單做法是用編輯距離或關(guān)鍵詞重合度不需要上模型。5. 進(jìn)階技巧用緩存命中率反推系統(tǒng)健康度上線之后別只盯著模型準(zhǔn)確率先看三個(gè)數(shù)會(huì)話緩存命中率、知識(shí)匹配命中率、模型調(diào)用占比。健康系統(tǒng)的模型調(diào)用占比應(yīng)該低于 40%也就是說超過一半的請求在前兩級就被消化了。如果這個(gè)數(shù)高于 70%說明你的緩存策略沒起作用或者知識(shí)庫覆蓋太差。我一般會(huì)在 Redis 里額外記一個(gè)計(jì)數(shù)器每次請求走完三級鏈路后INCR對應(yīng)的 key然后用 Grafana 看趨勢。緩存命中率突然下降通常是 TTL 配置被改了或者某個(gè)版本的代碼把 sessionId 生成邏輯改了導(dǎo)致 key 對不上。這種問題不看監(jiān)控很難發(fā)現(xiàn)等用戶投訴就晚了。另一個(gè)技巧是給流式輸出加一個(gè)“首字超時(shí)”兜底如果 3 秒內(nèi)沒有收到第一個(gè) chunk就主動(dòng)斷開并返回預(yù)設(shè)話術(shù)同時(shí)記錄一條日志。這樣用戶不會(huì)干等你也能知道模型側(cè)是不是出了問題。這個(gè)邏輯用Flux.timeout()就能實(shí)現(xiàn)比在前端做超時(shí)更可靠。最后說個(gè)我自己的習(xí)慣每次改緩存策略之前先把 Redis 里的會(huì)話樣本導(dǎo)出 100 條跑一遍離線回放看新的截?cái)噙壿嫊?huì)不會(huì)把關(guān)鍵上下文丟掉。這個(gè)動(dòng)作花不了十分鐘但能避免上線后“機(jī)器人突然變傻”的血淚事故。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取