上個(gè)月面完那家大廠回程地鐵上我腦子里還嗡嗡的。面試官最后一句是“你說(shuō)你去看過(guò)源碼那我再問(wèn)你一句Kafka冪等性到底在冪等什么”那一刻我就知道前面聊完Spring Boot線程池那些“基礎(chǔ)”只是開(kāi)胃菜真正的硬骨頭才開(kāi)始。介紹一下自己網(wǎng)名謝飛機(jī)Java后端開(kāi)發(fā)干了五年多每天都在跟Spring Boot、Kafka、中間件這些東西打交道。這次去面的是一個(gè)大廠核心業(yè)務(wù)團(tuán)隊(duì)的高級(jí)Java開(kāi)發(fā)崗。三輪面試面試官風(fēng)格完全不同第一輪是個(gè)喜歡摳底層原理的架構(gòu)師第二輪是做高并發(fā)平臺(tái)的大佬第三輪直接拋出一個(gè)“AI Agent 企業(yè)內(nèi)部RAG知識(shí)庫(kù)”的真實(shí)落地場(chǎng)景讓我現(xiàn)場(chǎng)給方案。說(shuō)實(shí)話這三輪我全都踩過(guò)坑也全都在現(xiàn)場(chǎng)補(bǔ)了回來(lái)。這篇就當(dāng)一次完整復(fù)盤。把三個(gè)方向的核心答案、實(shí)際踩坑過(guò)程以及我回來(lái)之后重新整理的生產(chǎn)配置方案一次性寫清楚。不管你是準(zhǔn)備面試還是正好在負(fù)責(zé)線程池調(diào)優(yōu)、Kafka可靠性改造、甚至是把AI Agent塞進(jìn)業(yè)務(wù)系統(tǒng)里的人應(yīng)該都能從這里撈到點(diǎn)東西。1. 第一輪施壓Spring Boot線程池從Tomcat到業(yè)務(wù)線程的“連環(huán)炮”1.1 現(xiàn)場(chǎng)還原面試官為什么從類加載器一路問(wèn)到這里第一輪面試官很老練上來(lái)沒(méi)讓我背八股先丟了一個(gè)生產(chǎn)問(wèn)題“我們有個(gè)網(wǎng)關(guān)服務(wù)Tomcat默認(rèn)工作線程數(shù)是200壓測(cè)時(shí)發(fā)現(xiàn)接口RT升高CPU卻跑不滿線程池隊(duì)列一直在堆積。你說(shuō)說(shuō)你會(huì)往哪幾個(gè)方向排查”我當(dāng)時(shí)第一反應(yīng)是這是一個(gè)典型的“線程池配置和流量模型不匹配”的問(wèn)題。我回答的時(shí)候先按自己的排查習(xí)慣說(shuō)了一遍先看線程池狀態(tài)是拒絕、是排隊(duì)還是空閑再看消息鏈路里有沒(méi)有阻塞點(diǎn)比如數(shù)據(jù)庫(kù)連接池、外部HTTP調(diào)用超時(shí)時(shí)間最后對(duì)比壓測(cè)QPS和單次請(qǐng)求耗時(shí)反推并發(fā)線程數(shù)需求。面試官點(diǎn)了點(diǎn)頭緊接著就問(wèn)了第二句“那你專門講講Spring Boot里的線程池Async用的是什么線程池不配置默認(rèn)是什么”這個(gè)問(wèn)題看似基礎(chǔ)實(shí)際是整套連環(huán)炮的入口。真正的考點(diǎn)不是“知不知道默認(rèn)配置”而是“知不知道默認(rèn)配置在真實(shí)流量下意味著什么”。我把面試現(xiàn)場(chǎng)的關(guān)鍵幾個(gè)問(wèn)答還原一下你感受一下節(jié)奏面試官Async不指定線程池Spring Boot默認(rèn)給你的是什么我TaskExecutionAutoConfiguration自動(dòng)配置的ThreadPoolTaskExecutor核心線程數(shù)默認(rèn)8最大線程數(shù)其實(shí)是Integer.MAX_VALUE隊(duì)列用的是無(wú)界LinkedBlockingQueue空閑線程存活60秒。面試官那你說(shuō)這個(gè)配置下核心線程滿了以后新任務(wù)去哪我去無(wú)界隊(duì)列排隊(duì)。無(wú)界隊(duì)列意味著隊(duì)列永遠(yuǎn)不會(huì)滿所以最大線程數(shù)這個(gè)參數(shù)在默認(rèn)配置下形同虛設(shè)真正干活的只有核心線程那8個(gè)剩下全部排隊(duì)。這就是“CPU不滿、RT卻一直漲”的典型癥狀。面試官如果要改你會(huì)怎么定核心線程數(shù)、最大線程數(shù)、隊(duì)列長(zhǎng)度我按流量模型算不能拍腦袋。比如單請(qǐng)求平均耗時(shí)50ms要支撐200 QPS穩(wěn)態(tài)并發(fā)就是200*0.0510核心線程數(shù)至少10以上再考慮峰值和限流留出彈性余量最大線程數(shù)可以到20左右隊(duì)列給一個(gè)有界值比如200不要讓任務(wù)無(wú)限堆積堆滿了就觸發(fā)拒絕策略把壓力傳到上游或者直接快速失敗。這一段對(duì)話結(jié)束以后我很明顯感覺(jué)到面試官的反饋是正向的。他要的不是“我會(huì)用ThreadPoolExecutor”而是“我知道它底層怎么流轉(zhuǎn)也清楚什么配置在什么場(chǎng)景下會(huì)出問(wèn)題”。1.2 復(fù)盤線程池面試題背后的核心考點(diǎn)現(xiàn)在把知識(shí)拆開(kāi)細(xì)講。ThreadPoolExecutor的任務(wù)流轉(zhuǎn)順序是固定的核心線程池滿了之后新任務(wù)先進(jìn)隊(duì)列隊(duì)列滿了才創(chuàng)建非核心線程直到最大線程數(shù)最大線程數(shù)也滿了才觸發(fā)拒絕策略。很多人背過(guò)這個(gè)順序但項(xiàng)目里一遇到問(wèn)題就忘因?yàn)榇蠹伊?xí)慣性把“核心線程數(shù)”和“最大線程數(shù)”之間的關(guān)系搞混。Spring Boot默認(rèn)的TaskExecutor問(wèn)題就出在無(wú)界隊(duì)列上。無(wú)界隊(duì)列下隊(duì)列永遠(yuǎn)不會(huì)滿所以“最大線程數(shù)”這個(gè)參數(shù)徹底失效。你看到的效果就是不管壓測(cè)QPS多高始終只有8個(gè)線程在工作其他任務(wù)全在隊(duì)列里排隊(duì)CPU自然跑不滿RT自然直線上升。更麻煩的是如果任務(wù)長(zhǎng)時(shí)間積壓隊(duì)列里的對(duì)象還會(huì)占用大量堆內(nèi)存最終引發(fā)Full GC甚至OOM。還有一層是面試官經(jīng)常挖的坑Tomcat工作線程和業(yè)務(wù)線程池是兩個(gè)不同的池。Tomcat的工作線程處理的是HTTP請(qǐng)求的接入默認(rèn)maxThreads200負(fù)責(zé)從Socket里讀請(qǐng)求、寫響應(yīng)而你在業(yè)務(wù)代碼里用Async或者自定義線程池是請(qǐng)求進(jìn)入Controller之后再把任務(wù)丟給另一個(gè)池子執(zhí)行。兩個(gè)池的配置相互獨(dú)立壓測(cè)時(shí)如果發(fā)現(xiàn)Tomcat線程堆積和業(yè)務(wù)線程池堆積排查方向完全是兩回事。至于線程數(shù)怎么定我習(xí)慣用“阻塞系數(shù)”來(lái)算而不是記網(wǎng)上的公式。IO密集型場(chǎng)景下線程數(shù)大約是CPU核數(shù)2再除以(1-阻塞系數(shù))比如8核機(jī)器、阻塞系數(shù)0.8大約需要82/(1-0.8)80個(gè)線程。這里的阻塞系數(shù)指的是線程在等待IO數(shù)據(jù)庫(kù)查詢、遠(yuǎn)程調(diào)用、磁盤讀寫上的時(shí)間占比越接近1說(shuō)明等待越嚴(yán)重需要更多線程來(lái)掩蓋延遲。CPU密集型場(chǎng)景則簡(jiǎn)單得多通常就是CPU核數(shù)加1因?yàn)槎嘁稽c(diǎn)上下文切換反而更劃算。這套算法不是為了精確而是讓你有一個(gè)可推導(dǎo)的起點(diǎn)而不是隨手填一個(gè)數(shù)字。1.3 實(shí)操配置線程池參數(shù)不靠猜靠算面完回來(lái)之后我把自己負(fù)責(zé)的那幾個(gè)服務(wù)全部排查了一遍統(tǒng)一改成了下面這套有界隊(duì)列配置實(shí)測(cè)下來(lái)比默認(rèn)配置穩(wěn)很多。Configuration public class BizThreadPoolConfig { Bean(bizTaskExecutor) public ThreadPoolTaskExecutor bizTaskExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); // 核心線程數(shù)按“穩(wěn)態(tài)QPS * 單任務(wù)耗時(shí)”算出來(lái)而不是拍腦袋 // 假設(shè)穩(wěn)態(tài) QPS 150單任務(wù)平均耗時(shí) 80ms并發(fā)需求 150 * 0.08 12 executor.setCorePoolSize(12); // 最大線程數(shù)核心線程 彈性容量容量給多少要看峰值流量和限流閾值 executor.setMaxPoolSize(24); // 有界隊(duì)列寧可觸發(fā)拒絕策略也別讓任務(wù)無(wú)限堆積占內(nèi)存 // 隊(duì)列長(zhǎng)度一般設(shè)為“最大線程數(shù)穩(wěn)態(tài)吞吐的1秒到2秒量” executor.setQueueCapacity(300); executor.setThreadNamePrefix(biz-worker-); executor.setKeepAliveSeconds(60); // 拒絕策略選 CallerRunsPolicy調(diào)用方線程自己跑相當(dāng)于天然限流 // 比 DiscardPolicy 好任務(wù)不會(huì)丟比 AbortPolicy 好不會(huì)無(wú)腦拋異常 executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); // 優(yōu)雅停機(jī)應(yīng)用關(guān)閉時(shí)先等已有任務(wù)跑完最多等30秒 executor.setWaitForTasksToCompleteOnShutdown(true); executor.setAwaitTerminationSeconds(30); executor.initialize(); return executor; } }這里面有三個(gè)細(xì)節(jié)值得多說(shuō)一句。第一拒絕策略我首選CallerRunsPolicy它的副作用是調(diào)用方線程會(huì)被占用等于把壓力反向傳導(dǎo)給上游會(huì)在不丟任務(wù)的前提下天然限流對(duì)支付、對(duì)賬這類不能丟消息的場(chǎng)景很友好。第二有界隊(duì)列的長(zhǎng)度必須跟最大線程數(shù)配合隊(duì)列太小會(huì)導(dǎo)致頻繁觸發(fā)拒絕策略太大又會(huì)失去“最大線程數(shù)”的意義我一般按“最大線程數(shù)在1秒到2秒內(nèi)的處理能力”來(lái)估也就是最大線程數(shù)乘以單個(gè)任務(wù)耗時(shí)再乘個(gè)系數(shù)。第三Async一定要指定自定義的bean名稱否則Spring Boot還是會(huì)走默認(rèn)的無(wú)界隊(duì)列配置。2. 第二輪追問(wèn)Kafka冪等性你說(shuō)你用過(guò)那你給我講清楚2.1 現(xiàn)場(chǎng)還原冪等性一問(wèn)到底第二輪面試官是做高并發(fā)中間件平臺(tái)的說(shuō)話節(jié)奏快問(wèn)題密度高。他上來(lái)直接問(wèn)“你們項(xiàng)目里用了Kafka吧生產(chǎn)端開(kāi)沒(méi)開(kāi)冪等”我說(shuō)開(kāi)了他緊接著就是三連。第一個(gè)問(wèn)題開(kāi)了冪等它底層是靠哪幾個(gè)關(guān)鍵字段保證不重復(fù)的第二個(gè)問(wèn)題冪等生產(chǎn)者能不能跨分區(qū)保證嚴(yán)格不重復(fù)第三個(gè)問(wèn)題業(yè)務(wù)要求一條消息只能被消費(fèi)一次冪等生產(chǎn)者能不能覆蓋覆蓋不了的話你怎么辦這三個(gè)問(wèn)題我現(xiàn)場(chǎng)答得并不順暢尤其是第三個(gè)我當(dāng)時(shí)只想到了“在消費(fèi)端做去重”但沒(méi)有及時(shí)說(shuō)出“冪等生產(chǎn)者只保生產(chǎn)端不重復(fù)消費(fèi)端在at-least-once語(yǔ)義下照樣可能重復(fù)消費(fèi)”這句話。好在面試官愿意引導(dǎo)我才把整個(gè)鏈路串起來(lái)了。2.2 原理拆解冪等生產(chǎn)者到底在冪等什么Kafka冪等生產(chǎn)者的核心機(jī)制是生產(chǎn)端和broker端共同維護(hù)一對(duì)狀態(tài)字段PIDProduceId生產(chǎn)者ID和Sequence Number序列號(hào)。生產(chǎn)者啟動(dòng)后會(huì)被分配一個(gè)PID在發(fā)送消息時(shí)每個(gè)分區(qū)都會(huì)維護(hù)一個(gè)從0開(kāi)始單調(diào)遞增的Sequence Number每發(fā)一條消息就加1broker端收到消息后會(huì)校驗(yàn)這個(gè)序號(hào)只接受“當(dāng)前已接收序號(hào)1”的批次如果收到的序號(hào)比已記錄的小或者出現(xiàn)跳號(hào)就判定為重復(fù)或亂序直接拒絕并拋出異常。所以Kafka冪等性真正保證的是同一個(gè)PID、同一個(gè)分區(qū)、短暫重試場(chǎng)景下的不重復(fù)和有序。它的場(chǎng)景是解決“生產(chǎn)者發(fā)送消息后沒(méi)收到ack于是重試導(dǎo)致broker收到兩條相同的消息”這類問(wèn)題。注意幾個(gè)邊界。第一PID不是永久不變的。生產(chǎn)者進(jìn)程重啟之后PID會(huì)變之前記錄的Sequence Number狀態(tài)全部失效重啟前可能已經(jīng)提交但未回調(diào)成功的那批消息是有極小概率重復(fù)的。第二跨分區(qū)沒(méi)有統(tǒng)一的序列號(hào)一個(gè)事務(wù)里寫多個(gè)分區(qū)每個(gè)分區(qū)各自維護(hù)各自的Sequence Number所以冪等生產(chǎn)者不能保證跨分區(qū)的原子性和全局不重復(fù)。第三分區(qū)Leader切換或者broker故障恢復(fù)的過(guò)程中如果狀態(tài)日志沒(méi)有完全同步也可能出現(xiàn)少量重復(fù)。那如果非要做到跨分區(qū)的不重不丟怎么辦答案是Kafka事務(wù)。事務(wù)型生產(chǎn)者會(huì)額外指定一個(gè)transactional.id它和PID綁定通過(guò)事務(wù)協(xié)調(diào)器維護(hù)跨分區(qū)的事務(wù)狀態(tài)消息先緩存在事務(wù)里最后統(tǒng)一commit后對(duì)消費(fèi)者可見(jiàn)。消費(fèi)者端還需要配合配置isolation.levelread_committed才能只讀取已提交的事務(wù)消息。這個(gè)方案能解決跨分區(qū)原子寫的問(wèn)題但有性能損耗而且在項(xiàng)目里真正會(huì)用到的場(chǎng)景其實(shí)不多通常只有“從Kafka讀數(shù)據(jù)處理后寫回另一個(gè)Kafka再寫數(shù)據(jù)庫(kù)要保證we所有環(huán)節(jié)要么全部成功要么全部失敗”這種跨系統(tǒng)一致性訴求。2.3 高并發(fā)場(chǎng)景的冪等實(shí)操生產(chǎn)端配置與消費(fèi)端去重回來(lái)之后我把項(xiàng)目的Kafka生產(chǎn)配置整理成了下面這份可以作為標(biāo)準(zhǔn)模板。spring: kafka: bootstrap-servers: kafka1:9092,kafka2:9092,kafka3:9092 producer: acks: all retries: 3 enable-idempotence: true max-in-flight-requests-per-connection: 5 key-serializer: org.apache.kafka.common.serialization.StringSerializer value-serializer: org.apache.kafka.common.serialization.StringSerializer consumer: group-id: biz-order-group enable-auto-commit: false auto-offset-reset: earliest key-deserializer: org.apache.kafka.common.serialization.StringDeserializer value-deserializer: org.apache.kafka.common.serialization.StringDeserializerenable-idempotencetrue之后acks會(huì)被強(qiáng)制提升為allretries也建議開(kāi)大于0否則冪等沒(méi)有意義。max-in-flight-requests-per-connection在新版本里可以設(shè)置為5但如果你在舊版本上還是保守一點(diǎn)設(shè)成1避免亂序觸發(fā)OutOfOrderSequenceException。這個(gè)屬性的作用是控制單個(gè)連接上最多有多少個(gè)未確認(rèn)的請(qǐng)求在飛行設(shè)置越大吞吐越高但亂序風(fēng)險(xiǎn)也越大。然后是消費(fèi)端。很多人以為生產(chǎn)端開(kāi)了冪等消費(fèi)端就不會(huì)重復(fù)了這是最典型的認(rèn)知誤區(qū)。Kafka默認(rèn)的消費(fèi)語(yǔ)義是at-least-once也就是說(shuō)“消息不丟”但“可能重復(fù)”。正常流程是消費(fèi)者拉取一批消息處理完業(yè)務(wù)邏輯提交offset。如果業(yè)務(wù)邏輯執(zhí)行完、offset還沒(méi)來(lái)得及提交消費(fèi)者就掛了重啟后會(huì)從舊offset重新拉取這些消息就會(huì)被再次消費(fèi)。生產(chǎn)端冪等完全管不到這個(gè)過(guò)程。消費(fèi)端去重我一般用三個(gè)方案按場(chǎng)景選。第一Redis冪等標(biāo)記用業(yè)務(wù)唯一鍵比如訂單號(hào)作為keysetIfAbsent成功才繼續(xù)處理處理完成寫入結(jié)果適合高吞吐場(chǎng)景但要注意Redis和業(yè)務(wù)數(shù)據(jù)庫(kù)的一致性。第二數(shù)據(jù)庫(kù)唯一約束直接給業(yè)務(wù)表加唯一索引重復(fù)插入會(huì)報(bào)錯(cuò)然后捕獲異常跳過(guò)這是最硬的兜底但僅適合有唯一性特征的數(shù)據(jù)。第三狀態(tài)機(jī)冪等把每一條消息按業(yè)務(wù)主鍵查狀態(tài)只有在“當(dāng)前狀態(tài)允許流轉(zhuǎn)到目標(biāo)狀態(tài)”時(shí)才執(zhí)行更新否則跳過(guò)。我實(shí)際做項(xiàng)目時(shí)最喜歡“數(shù)據(jù)庫(kù)唯一約束 Redis標(biāo)記”組合一個(gè)保底一個(gè)擋流量。消費(fèi)端去重代碼的骨架大概是這個(gè)樣子// 偽代碼消費(fèi)前做冪等檢查 String key biz:processed: record.key(); Boolean first redisTemplate.opsForValue() .setIfAbsent(key, 1, Duration.ofHours(24)); if (Boolean.TRUE.equals(first)) { // 第一次消費(fèi)執(zhí)行業(yè)務(wù)邏輯 handle(record.value()); } else { // 已處理過(guò)跳過(guò)業(yè)務(wù)邏輯直接提交offset }注意Redis里的標(biāo)記盡量設(shè)置過(guò)期時(shí)間否則存量消息會(huì)越積越多同時(shí)消費(fèi)邏輯和Redis寫入之間要做好失敗補(bǔ)償比如先執(zhí)行消費(fèi)邏輯再寫Redis則可能出現(xiàn)重復(fù)執(zhí)行先寫Redis再執(zhí)行消費(fèi)邏輯則可能出現(xiàn)Redis已經(jīng)寫了但業(yè)務(wù)失敗導(dǎo)致后續(xù)消息被跳過(guò)。經(jīng)驗(yàn)做法是記錄狀態(tài)時(shí)要區(qū)分“處理中”和“已完成”兩種狀態(tài)處理中狀態(tài)帶超時(shí)時(shí)間完成后改成永久標(biāo)記。這樣即使業(yè)務(wù)失敗超時(shí)后還能重試不會(huì)漏消息。3. 第三輪開(kāi)放題AI Agent RAG落地技術(shù)細(xì)節(jié)與工程取舍3.1 情景還原面試官拿著一個(gè)質(zhì)檢場(chǎng)景讓我現(xiàn)場(chǎng)設(shè)計(jì)第三輪面試官明顯不是做純Java的他更像業(yè)務(wù)架構(gòu)師。他點(diǎn)開(kāi)屏幕上的一個(gè)需求文檔說(shuō)“我們想做一個(gè)面向一線質(zhì)檢人員的智能體。用戶上傳產(chǎn)品缺陷照片智能體要能結(jié)合企業(yè)內(nèi)部知識(shí)庫(kù)回答這是什么缺陷、應(yīng)該怎么處理。這個(gè)場(chǎng)景就是AI Agent加RAG你從工程角度給我一個(gè)完整方案包括圖片怎么處理知識(shí)庫(kù)怎么存儲(chǔ)并發(fā)能不能扛住?！蔽耶?dāng)時(shí)心里一緊。因?yàn)檫@類場(chǎng)景我在公司內(nèi)部確實(shí)調(diào)研過(guò)但沒(méi)有真正上線過(guò)大規(guī)模生產(chǎn)系統(tǒng)所以回答時(shí)很謹(jǐn)慎。我先確認(rèn)了幾個(gè)關(guān)鍵信息知識(shí)庫(kù)有哪些格式圖片數(shù)量級(jí)有多大智能體是同步返回還是異步通知要不要考慮權(quán)限。然后給了下面這版方案面試官?zèng)]有打斷我說(shuō)明大方向是對(duì)的。3.2 RAG知識(shí)庫(kù)的圖片存儲(chǔ)能存圖片但重點(diǎn)在“怎么被檢索”先說(shuō)結(jié)論RAG知識(shí)庫(kù)當(dāng)然能存儲(chǔ)圖片。OSS、S3、本地文件系統(tǒng)甚至數(shù)據(jù)庫(kù)里的BLOB字段都能存圖片。真正的難點(diǎn)是圖片怎么被檢索、怎么和文本知識(shí)統(tǒng)一召回。RAG的核心不是“存”而是“找”。檢索階段系統(tǒng)需要把文本問(wèn)題和知識(shí)庫(kù)內(nèi)容都映射到一個(gè)向量空間用向量相似度找出最相關(guān)的片段。純文本場(chǎng)景好辦用Embedding模型生成文本向量就行。圖片場(chǎng)景就需要多模態(tài)能力。實(shí)際落地有三種做法。第一種是圖片生成獨(dú)立向量用CLIP這類多模態(tài)模型把整張圖片編碼成一個(gè)向量查詢時(shí)用戶的圖片也編碼成向量做相似度檢索。這種方案能感知圖片的視覺(jué)內(nèi)容但工程復(fù)雜度高向量模型對(duì)顯卡算力有要求。第二種是圖片轉(zhuǎn)文本再入庫(kù)先對(duì)圖片做OCR再配合人工標(biāo)注或視覺(jué)大模型生成一段描述文本把這段文本和圖片路徑一起入庫(kù)檢索時(shí)只走文本召回命中后返回圖片。這種方式成本低、效果好目前很多企業(yè)實(shí)測(cè)下來(lái)最實(shí)用。第三種是混合方案圖片向量和文本描述都存檢索時(shí)多路召回再融合效果最好但也最復(fù)雜。我當(dāng)時(shí)給面試官的方案是第二種為主、第三種做演進(jìn)。原因是一線質(zhì)檢場(chǎng)景里缺陷類型往往集中在有限的幾十種人工標(biāo)注的成本是可控的OCR加描述生成的文本能讓知識(shí)庫(kù)的檢索質(zhì)量快速達(dá)到可用水平。等數(shù)據(jù)量大了、算力資源充足了再引入多模態(tài)向量。面試官追問(wèn)了一句“向量庫(kù)里到底存什么”我補(bǔ)充說(shuō)向量庫(kù)只存向量和metadata圖片ID、文本、產(chǎn)品型號(hào)、缺陷編碼圖片本體放OSS查詢結(jié)果里帶著OSS的URL給前端展示。這個(gè)回答他應(yīng)該是認(rèn)可的因?yàn)檫@就是今天大多數(shù)企業(yè)知識(shí)庫(kù)的常規(guī)架構(gòu)。3.3 RAG落地瓶頸切分、召回、上下文一個(gè)都不能偷懶RAG項(xiàng)目最大的特點(diǎn)就是“細(xì)節(jié)多每一個(gè)環(huán)節(jié)都可能讓效果斷崖式下降”。我給它排了個(gè)序切分、召回、重排、上下文管理。這四個(gè)環(huán)節(jié)任何一個(gè)做不好回答質(zhì)量都會(huì)拉胯。切分是第一個(gè)容易翻車的點(diǎn)。固定按512字符切分、重疊128字符是最常見(jiàn)的做法但你要知道這不是銀彈。如果你的文檔里大量是表格、代碼塊、層級(jí)標(biāo)題固定長(zhǎng)度切分會(huì)把語(yǔ)義拆得七零八落檢索的時(shí)候經(jīng)常匹配到一半內(nèi)容。更好的做法是按語(yǔ)義邊界切分比如檢測(cè)到新的二級(jí)標(biāo)題就自動(dòng)換一個(gè)Chunk表格轉(zhuǎn)成文本后再切代碼塊單獨(dú)處理。切分時(shí)還要保留塊與塊之間的上下文關(guān)系比如每個(gè)Chunk里附帶文檔標(biāo)題、父級(jí)章節(jié)檢索時(shí)可以按父級(jí)信息做“二次聚類”。召回是整個(gè)RAG效果的關(guān)鍵瓶頸。只用向量召回偶爾會(huì)發(fā)現(xiàn)語(yǔ)義相近但關(guān)鍵詞完全不搭的內(nèi)容召不回來(lái)。業(yè)界目前比較成熟的做法是多路召回加Rerank向量召回取Top20關(guān)鍵詞召回BM25取Top20合并去重后交給一個(gè)Rerank模型重新打分再取Top5送給大模型。Rerank模型不便宜但是這一步帶來(lái)的效果提升非常明顯很多從“勉強(qiáng)能用”到“生產(chǎn)可用”的跨越就是靠加了一層Rerank實(shí)現(xiàn)的。上下文管理是另一個(gè)隱性瓶頸。你有Top5的Chunk每個(gè)Chunk可能1000多字加系統(tǒng)提示詞、歷史對(duì)話一次性塞給大模型很容易沖爆Token上限。處理方式有幾種按MaxToken限制動(dòng)態(tài)裁剪Chunk只保留每個(gè)Chunk里和問(wèn)題高相關(guān)的句子引入長(zhǎng)會(huì)話緩存把歷史對(duì)話壓縮成摘要再重新作為上下文或采用Agentic RAG的思路讓智能體自己決定需要檢索幾次、每次檢索什么而不是把所有內(nèi)容一次性塞進(jìn)去。Agentic RAG的好處是讓“檢索”從一次性的動(dòng)作變成了可決策的動(dòng)作能回答更復(fù)雜的問(wèn)題但也意味著單次請(qǐng)求的LLM調(diào)用次數(shù)變多、延遲變高這兩個(gè)方向本身就是互斥的要在工程上做平衡。3.4 AI Agent怎么扛并發(fā)大模型調(diào)用是瓶頸架構(gòu)要對(duì)癥下藥面試官問(wèn)“AI Agent怎么扛并發(fā)”的邏輯其實(shí)是所有Java后端人員在做AI應(yīng)用時(shí)都要面對(duì)的一道坎。傳統(tǒng)接口的瓶頸在IO、數(shù)據(jù)庫(kù)、緩存而AI Agent的瓶頸在大模型推理。一個(gè)Agent請(qǐng)求內(nèi)部可能要調(diào)用四五次LLM理解用戶意圖一次、規(guī)劃任務(wù)一次、檢索后生成答案一次、可能還要做自我糾錯(cuò)再調(diào)一次。單次LLM調(diào)用就要2秒到10秒一次請(qǐng)求幾十秒非常正常。這時(shí)候如果網(wǎng)關(guān)線程池傻傻地同步等待用不了多少Q(mào)PS就能把整個(gè)服務(wù)拖死。我的方案分四層。第一層接口層異步化收到請(qǐng)求后立刻返回任務(wù)ID后端消費(fèi)者把任務(wù)丟進(jìn)隊(duì)列處理完成后通過(guò)WebSocket、SSE或者輪詢接口通知前端。這樣Tomcat線程不會(huì)被長(zhǎng)時(shí)間占用。第二層智能體任務(wù)編排層做并行化多個(gè)獨(dú)立的檢索、多個(gè)獨(dú)立的數(shù)據(jù)查詢并行執(zhí)行把串行鏈路變成DAG能大幅縮短響應(yīng)時(shí)間。第三層緩存層最直接的是結(jié)果緩存相同問(wèn)題直接返回歷史答案進(jìn)階一點(diǎn)是語(yǔ)義緩存把用戶問(wèn)題向量化和緩存里的歷史問(wèn)題做相似度判斷相似度超過(guò)閾值的直接復(fù)用答案。這塊是真的能省錢的很多知識(shí)庫(kù)問(wèn)答場(chǎng)景命中率能做到40%以上。第四層限流降級(jí)再兜底為AI調(diào)用設(shè)置專有線程池并和普通業(yè)務(wù)線程池做隔離按客戶等級(jí)做限流LLM調(diào)用失敗時(shí)走預(yù)設(shè)的兜底話術(shù)或規(guī)則引擎保證用戶體驗(yàn)不至于斷崖。有一點(diǎn)特別值得展開(kāi)說(shuō)線程池隔離背后的并發(fā)計(jì)算邏輯。假設(shè)每個(gè)Agent請(qǐng)求平均需要60秒才能拿結(jié)果一個(gè)8線程的worker池同一時(shí)刻只能處理8個(gè)請(qǐng)求每個(gè)線程一秒鐘最多完成1/60個(gè)請(qǐng)求整個(gè)池子的總吞吐就是8/60約等于0.13 QPS。如果你能通過(guò)并行化把單請(qǐng)求耗時(shí)壓縮到10秒同樣的線程池吞吐直接變成8/100.8 QPS提升了6倍。這個(gè)計(jì)算說(shuō)明AI Agent扛并發(fā)的核心不是無(wú)限加機(jī)器而是想方設(shè)法降低單請(qǐng)求持有線程的時(shí)間。這也是為什么“異步化”和“盡快釋放線程”在AI場(chǎng)景里比在傳統(tǒng)Web場(chǎng)景里重要得多。4. 三輪面試之后我整理的一份“面試避坑快查表”4.1 高頻問(wèn)題速查表面完第三天我把面試中涉及的關(guān)鍵知識(shí)點(diǎn)做了一張速查表發(fā)在團(tuán)隊(duì)內(nèi)部群里幾個(gè)同事說(shuō)挺有用?，F(xiàn)在貼在下面。場(chǎng)景高頻現(xiàn)象根因分析解決/應(yīng)對(duì)方案Spring Boot AsyncCPU不滿、RT升高、線程堆積默認(rèn)無(wú)界隊(duì)列core8最大線程參數(shù)失效自定義有界隊(duì)列線程池按QPS*耗時(shí)算核心數(shù)ThreadPoolExecutor隊(duì)列滿了直接拋RejectedExecutionException默認(rèn)AbortPolicy按業(yè)務(wù)選CallerRunsPolicy或定制降級(jí)策略Kafka生產(chǎn)端開(kāi)啟冪等后仍擔(dān)心跨分區(qū)重復(fù)冪等只?！癙ID分區(qū)序號(hào)”不保證全局需要全局一致性時(shí)用事務(wù)型ProducerKafka消費(fèi)端數(shù)據(jù)重復(fù)入庫(kù)at-least-once語(yǔ)義offset未提交導(dǎo)致重復(fù)拉取Redis標(biāo)記/數(shù)據(jù)庫(kù)唯一約束/狀態(tài)機(jī)RAG知識(shí)庫(kù)圖片檢索不到圖片沒(méi)有轉(zhuǎn)成可檢索的文本或向量OCR描述文本入庫(kù)或CLIP多模態(tài)向量RAG檢索效果差召回結(jié)果與問(wèn)題不相關(guān)單一向量召回不準(zhǔn)多路召回BM25向量 RerankAI Agent并發(fā)請(qǐng)求一多服務(wù)直接不可用LLM調(diào)用慢、同步阻塞持線程異步化任務(wù)并行化語(yǔ)義緩存線程池隔離4.2 排查現(xiàn)場(chǎng)問(wèn)題的幾個(gè)實(shí)操路徑除了背知識(shí)點(diǎn)面試官更看重“遇到線上問(wèn)題怎么排”。我的習(xí)慣是先看線程池的運(yùn)行狀態(tài)再看鏈路耗時(shí)最后看消息隊(duì)列的堆積和消費(fèi)速率。線程池可以通過(guò)Spring Boot Actuator暴露的metrics看active線程數(shù)和隊(duì)列剩余量也可以通過(guò)jstack抓線程dump看線程池里到底都在執(zhí)行什么。如果線程全部WAITING在某個(gè)鎖上那就不是線程數(shù)的問(wèn)題而是鎖競(jìng)爭(zhēng)的問(wèn)題。Kafka排查延遲高時(shí)先分清楚是生產(chǎn)端延遲還是消費(fèi)端延遲。生產(chǎn)端要看broker端CPU、網(wǎng)絡(luò)帶寬、acksall時(shí)的副本同步情況以及有沒(méi)有頻繁重試消費(fèi)端要看消費(fèi)組是否發(fā)生Rebalance、單條消息處理耗時(shí)、消費(fèi)線程數(shù)是否小于分區(qū)數(shù)。之前遇到過(guò)一次消費(fèi)端延遲高最后發(fā)現(xiàn)是消費(fèi)組里一個(gè)實(shí)例的GC時(shí)間過(guò)長(zhǎng)導(dǎo)致心跳超時(shí)頻繁觸發(fā)Rebalance消費(fèi)根本沒(méi)進(jìn)度。這個(gè)排查順序很通用先隔離再分層看指標(biāo)。RAG應(yīng)用出問(wèn)題優(yōu)先查的是“檢索環(huán)節(jié)”而不是“生成環(huán)節(jié)”。如果大模型回答得不好先看Top5的召回片段里到底有沒(méi)有正確答案。如果正確答案沒(méi)有被召回問(wèn)題在切分和檢索如果正確答案被召回了但大模型沒(méi)用上才是提示詞或上下文組裝的問(wèn)題。這個(gè)排查順序能讓定位問(wèn)題的效率高非常多別一上來(lái)就調(diào)prompt。5. 一些真實(shí)心里話這類面試到底在考什么三輪面完之后我最大的感受是大廠面試早就不是考“你用過(guò)什么框架”而是考“你在一線踩坑之后有沒(méi)有真正形成方法論”。Spring Boot線程池那輪真正區(qū)分人的不是知不知道默認(rèn)線程數(shù)是8而是能不能說(shuō)清楚無(wú)界隊(duì)列為什么危險(xiǎn)、核心線程數(shù)怎么根據(jù)流量算出來(lái)。Kafka冪等性那輪區(qū)分人的也不是背不背得出PID和Sequence Number而是能不能意識(shí)到“生產(chǎn)端冪等≠消費(fèi)端冪等”以及遇到跨分區(qū)一致性問(wèn)題時(shí)有什么工具可用。AI Agent和RAG那輪面試官根本不在意你是不是AI專家他在意的是你有沒(méi)有系統(tǒng)工程思維知不知道圖片知識(shí)庫(kù)的存儲(chǔ)與檢索是兩件不同的事知不知道大模型調(diào)用的延遲會(huì)對(duì)整個(gè)后端線程模型造成什么沖擊?；貋?lái)之后我做了一件事把現(xiàn)在負(fù)責(zé)的系統(tǒng)里所有沒(méi)指定線程池的Async全部抓出來(lái)改成了有界隊(duì)列版本給Kafka消費(fèi)者補(bǔ)了Redis冪等標(biāo)記還把多模態(tài)RAG的圖片入庫(kù)方案整理成了一篇設(shè)計(jì)文檔準(zhǔn)備在下次迭代里試點(diǎn)。這不是為了“把面試上答不上的補(bǔ)回來(lái)”而是這些內(nèi)容本來(lái)就是生產(chǎn)系統(tǒng)里值得做的事。面試只是把平時(shí)欠的賬翻出來(lái)給你看而已。最后分享一個(gè)小心得面試遇到不會(huì)的問(wèn)題別急著編也別直接說(shuō)不會(huì)。先說(shuō)自己的第一反應(yīng)再把問(wèn)題拆成兩三個(gè)子問(wèn)題一個(gè)一個(gè)往下推。大多數(shù)面試官愿意聽(tīng)思考過(guò)程因?yàn)檎鎸?shí)工作里也沒(méi)有人一口氣給出標(biāo)準(zhǔn)答案。把過(guò)程講清楚哪怕結(jié)論不完美也遠(yuǎn)好過(guò)給出一個(gè)背得滾瓜爛熟但經(jīng)不起追問(wèn)的標(biāo)準(zhǔn)答案。