1. 為什么我選擇用Java啃下招聘網(wǎng)站這塊硬骨頭做數(shù)據(jù)分析和求職輔助工具的人繞不開的一個(gè)需求就是批量獲取招聘崗位信息。我最早用Python的requests加BeautifulSoup寫過一版跑得挺順但后來項(xiàng)目要集成到一個(gè)已有的Java后臺(tái)管理系統(tǒng)里團(tuán)隊(duì)技術(shù)棧清一色Java再維護(hù)兩套語言成本太高索性把采集模塊整個(gè)用Java重寫了一遍。這篇文章就是那次重寫過程中沉淀下來的完整思路和踩坑記錄。招聘類網(wǎng)站的數(shù)據(jù)價(jià)值不用多說——崗位名稱、薪資范圍、學(xué)歷要求、經(jīng)驗(yàn)門檻、技能標(biāo)簽、公司規(guī)模、融資階段這些字段組合起來能做很多事分析某個(gè)技術(shù)方向的市場(chǎng)需求走勢(shì)、對(duì)比不同城市的薪資差異、給求職者做崗位匹配推薦、甚至幫培訓(xùn)機(jī)構(gòu)判斷該開什么課。但這類網(wǎng)站的數(shù)據(jù)不是白給的它們有反爬機(jī)制、有登錄墻、有動(dòng)態(tài)渲染直接硬來基本是碰一鼻子灰。Java做網(wǎng)絡(luò)爬蟲的優(yōu)勢(shì)在于生態(tài)成熟、并發(fā)能力強(qiáng)、和業(yè)務(wù)系統(tǒng)集成方便。HttpClient負(fù)責(zé)發(fā)請(qǐng)求Jsoup負(fù)責(zé)解析HTMLJackson或Fastjson負(fù)責(zé)處理JSON再加上線程池做并發(fā)控制一套組合拳下來能覆蓋絕大多數(shù)采集場(chǎng)景。這篇文章適合有Java基礎(chǔ)、想動(dòng)手做數(shù)據(jù)采集的開發(fā)者也適合已經(jīng)寫過簡(jiǎn)單爬蟲但遇到反爬就卡住的人。我會(huì)從目標(biāo)分析、請(qǐng)求構(gòu)造、頁面解析、反爬應(yīng)對(duì)、數(shù)據(jù)存儲(chǔ)這幾個(gè)維度把整個(gè)流程拆開講透代碼可以直接參考復(fù)現(xiàn)。需要提前說明的是本文討論的技術(shù)方案僅用于學(xué)習(xí)和技術(shù)研究目的實(shí)際使用時(shí)請(qǐng)遵守目標(biāo)網(wǎng)站的服務(wù)條款和相關(guān)法律法規(guī)控制采集頻率不要對(duì)目標(biāo)服務(wù)器造成壓力。技術(shù)本身是中性的怎么用取決于使用的人。2. 動(dòng)手之前先把目標(biāo)網(wǎng)站的請(qǐng)求鏈路摸清楚2.1 從瀏覽器開發(fā)者工具里挖出真正的數(shù)據(jù)接口很多人寫爬蟲的第一步是直接拿URL去請(qǐng)求HTML然后發(fā)現(xiàn)返回的內(nèi)容里根本沒有崗位數(shù)據(jù)。這是因?yàn)楝F(xiàn)代招聘網(wǎng)站基本都是前后端分離架構(gòu)頁面骨架是靜態(tài)的崗位列表是JavaScript異步加載的。你右鍵查看網(wǎng)頁源代碼看到的可能只是一堆div容器真正的數(shù)據(jù)藏在XHR請(qǐng)求的響應(yīng)里。正確的做法是打開瀏覽器的開發(fā)者工具切到Network面板篩選XHR或Fetch請(qǐng)求然后刷新頁面或滾動(dòng)加載更多崗位。你會(huì)看到一系列接口請(qǐng)求響應(yīng)格式通常是JSON。找到那個(gè)返回崗位列表的接口把它的請(qǐng)求URL、請(qǐng)求方法、請(qǐng)求頭、請(qǐng)求參數(shù)全部記錄下來。這一步是整個(gè)爬蟲的地基地基沒打?qū)竺嫒踪M(fèi)。以我實(shí)際分析的某招聘平臺(tái)為例它的崗位搜索接口大致是這樣的結(jié)構(gòu)一個(gè)GET請(qǐng)求URL里帶了query參數(shù)搜索關(guān)鍵詞、city參數(shù)城市編碼、page參數(shù)頁碼請(qǐng)求頭里必須帶User-Agent、Referer、Cookie等字段。響應(yīng)是一個(gè)JSON對(duì)象里面有個(gè)data字段data里又有jobList數(shù)組每個(gè)元素包含jobName、salaryDesc、jobLabels、skills、experienceName等字段。這些字段名就是后面解析時(shí)的key。注意不同招聘平臺(tái)的接口結(jié)構(gòu)差異很大有的用POST有的參數(shù)做了加密簽名有的需要登錄態(tài)。不要照搬某個(gè)平臺(tái)的方案一定要自己動(dòng)手分析目標(biāo)平臺(tái)的實(shí)際請(qǐng)求。2.2 請(qǐng)求頭里哪些字段是必須帶的分析接口的時(shí)候重點(diǎn)看請(qǐng)求頭。以下幾個(gè)字段通常缺一不可User-Agent標(biāo)識(shí)客戶端類型不帶的話服務(wù)器可能直接返回403。建議用真實(shí)瀏覽器的UA字符串不要用Java默認(rèn)的。Referer告訴服務(wù)器你是從哪個(gè)頁面發(fā)起的請(qǐng)求很多網(wǎng)站會(huì)校驗(yàn)這個(gè)字段。Cookie維持會(huì)話狀態(tài)有些接口需要登錄后才能訪問Cookie里帶著身份憑證。Accept聲明期望的響應(yīng)格式一般設(shè)為application/json或text/html。X-Requested-With部分網(wǎng)站用它判斷是不是Ajax請(qǐng)求設(shè)為XMLHttpRequest。我習(xí)慣在代碼里把這些請(qǐng)求頭集中管理用一個(gè)Map或者配置類存起來方便統(tǒng)一修改。下面是一個(gè)典型的請(qǐng)求頭配置示例MapString, String headers new HashMap(); headers.put(User-Agent, Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36); headers.put(Referer, https://example.com/job/search); headers.put(Accept, application/json, text/plain, */*); headers.put(Accept-Language, zh-CN,zh;q0.9); headers.put(Cookie, 你的Cookie字符串);2.3 分頁參數(shù)與城市編碼的對(duì)應(yīng)關(guān)系招聘網(wǎng)站的搜索接口通常支持分頁page參數(shù)從1開始遞增。但要注意有些平臺(tái)對(duì)翻頁深度有限制比如只允許查看前30頁或前100條記錄。超過限制后要么返回空數(shù)據(jù)要么要求登錄。這個(gè)限制在做數(shù)據(jù)量評(píng)估時(shí)必須提前確認(rèn)否則你寫了個(gè)循環(huán)跑了幾百頁結(jié)果后面全是重復(fù)數(shù)據(jù)或空響應(yīng)。城市編碼是另一個(gè)容易踩坑的地方。招聘網(wǎng)站一般用內(nèi)部編碼表示城市比如北京可能是101010100上海是101020100這些編碼不會(huì)直接顯示在頁面上需要從接口請(qǐng)求參數(shù)里抓取或者從網(wǎng)站的城市列表接口獲取。我的做法是先手動(dòng)搜索一次目標(biāo)城市在Network面板里找到實(shí)際發(fā)出的請(qǐng)求把city參數(shù)的值記下來硬編碼到一個(gè)枚舉或配置文件中。public enum CityEnum { BEIJING(101010100, 北京), SHANGHAI(101020100, 上海), GUANGZHOU(101280100, 廣州), SHENZHEN(101280600, 深圳); private final String code; private final String name; CityEnum(String code, String name) { this.code code; this.name name; } public String getCode() { return code; } public String getName() { return name; } }3. 用HttpClient構(gòu)建一個(gè)能扛住壓力的請(qǐng)求層3.1 連接池配置與超時(shí)設(shè)置的門道Java原生的HttpURLConnection用起來太原始Apache HttpClient是更成熟的選擇。但很多人直接new一個(gè)CloseableHttpClient就開跑沒配連接池沒設(shè)超時(shí)跑幾十個(gè)請(qǐng)求還行上千個(gè)請(qǐng)求就開始報(bào)連接超時(shí)或資源耗盡。正確的做法是用PoolingHttpClientConnectionManager管理連接池設(shè)置最大連接數(shù)和每個(gè)路由的最大連接數(shù)。超時(shí)方面要分三層設(shè)置connectTimeout建立TCP連接的超時(shí)、socketTimeout等待數(shù)據(jù)的超時(shí)、connectionRequestTimeout從連接池獲取連接的超時(shí)。這三個(gè)超時(shí)各有用途缺一不可。PoolingHttpClientConnectionManager connManager new PoolingHttpClientConnectionManager(); connManager.setMaxTotal(100); connManager.setDefaultMaxPerRoute(20); RequestConfig requestConfig RequestConfig.custom() .setConnectTimeout(5000) .setSocketTimeout(10000) .setConnectionRequestTimeout(3000) .build(); CloseableHttpClient httpClient HttpClients.custom() .setConnectionManager(connManager) .setDefaultRequestConfig(requestConfig) .build();實(shí)測(cè)下來connectTimeout設(shè)5秒、socketTimeout設(shè)10秒是比較穩(wěn)妥的區(qū)間。設(shè)太短容易誤殺正常請(qǐng)求設(shè)太長遇到死連接會(huì)拖慢整體進(jìn)度。連接池的maxTotal根據(jù)你的并發(fā)線程數(shù)來定一般設(shè)成線程數(shù)的2到3倍就夠了。3.2 重試機(jī)制不是簡(jiǎn)單加個(gè)循環(huán)網(wǎng)絡(luò)請(qǐng)求失敗是常態(tài)尤其是采集大量數(shù)據(jù)的時(shí)候。但重試不是無腦for循環(huán)重試三次就完事要區(qū)分哪些異常值得重試哪些重試也沒用。值得重試的情況連接超時(shí)、讀取超時(shí)、服務(wù)器返回502/503/504。不值得重試的情況403禁止訪問、404不存在、401未授權(quán)。前者是臨時(shí)性故障重試可能成功后者是權(quán)限或資源問題重試一百次結(jié)果一樣。HttpClient自帶了一個(gè)HttpRequestRetryHandler可以自定義重試邏輯HttpRequestRetryHandler retryHandler (exception, executionCount, context) - { if (executionCount 3) { return false; } if (exception instanceof ConnectTimeoutException) { return true; } if (exception instanceof SocketTimeoutException) { return true; } if (exception instanceof NoHttpResponseException) { return true; } return false; };把retryHandler設(shè)置到HttpClientBuilder上就能自動(dòng)處理重試。但要注意重試之間最好加個(gè)短暫的等待避免瞬間密集重試觸發(fā)風(fēng)控。3.3 代理IP的合理使用方式采集量大了之后單IP請(qǐng)求頻率過高會(huì)被限制。這時(shí)候需要引入代理IP池。代理的來源可以是商業(yè)代理服務(wù)也可以自建。使用方式是在請(qǐng)求配置里設(shè)置代理HttpHost proxy new HttpHost(代理IP, 端口); RequestConfig config RequestConfig.custom() .setProxy(proxy) .build();代理池的管理是個(gè)獨(dú)立話題核心思路是維護(hù)一個(gè)可用代理列表每次請(qǐng)求隨機(jī)選一個(gè)請(qǐng)求失敗則標(biāo)記該代理不可用并剔除定期補(bǔ)充新代理。我一般會(huì)寫一個(gè)ProxyPool類內(nèi)部用一個(gè)阻塞隊(duì)列存代理后臺(tái)線程定期檢測(cè)代理可用性。提示代理IP的質(zhì)量參差不齊免費(fèi)代理基本不能用商業(yè)代理也要先小批量測(cè)試。建議在正式采集前用一批代理跑一輪測(cè)試請(qǐng)求統(tǒng)計(jì)成功率和響應(yīng)時(shí)間篩選出可用的再投入生產(chǎn)。4. 解析JSON響應(yīng)與字段提取的實(shí)戰(zhàn)細(xì)節(jié)4.1 用Jackson做JSON反序列化的正確姿勢(shì)拿到接口返回的JSON字符串后下一步是解析出需要的字段。Jackson是Java生態(tài)里最常用的JSON庫性能好、功能全?；居梅ㄊ菢?gòu)建ObjectMapper然后readTree成JsonNode再按路徑逐層取值。ObjectMapper mapper new ObjectMapper(); JsonNode rootNode mapper.readTree(responseBody); JsonNode jobList rootNode.path(data).path(jobList); for (JsonNode job : jobList) { String jobName job.path(jobName).asText(); String salary job.path(salaryDesc).asText(); String experience job.path(experienceName).asText(); String degree job.path(degreeName).asText(); // 技能標(biāo)簽是一個(gè)數(shù)組 ListString skills new ArrayList(); JsonNode skillsNode job.path(skills); if (skillsNode.isArray()) { for (JsonNode skill : skillsNode) { skills.add(skill.asText()); } } }用path()而不是get()的好處是當(dāng)字段不存在時(shí)path()返回MissingNodeasText()返回空字符串不會(huì)拋NullPointerException。這在字段結(jié)構(gòu)不穩(wěn)定的接口里特別重要。4.2 薪資字段的清洗與結(jié)構(gòu)化招聘網(wǎng)站返回的薪資通常是一個(gè)字符串比如15-25K·13薪、20-40K、8-12K·14薪這種格式。直接存字符串沒法做數(shù)值分析需要拆解成最低薪資、最高薪資、薪資月數(shù)三個(gè)字段。public class SalaryParser { public static SalaryInfo parse(String salaryStr) { SalaryInfo info new SalaryInfo(); // 處理·13薪部分 int months 12; if (salaryStr.contains(·)) { String[] parts salaryStr.split(·); salaryStr parts[0]; String monthStr parts[1].replace(薪, ); months Integer.parseInt(monthStr); } // 處理15-25K部分 salaryStr salaryStr.replace(K, ).replace(k, ); if (salaryStr.contains(-)) { String[] range salaryStr.split(-); info.setMinSalary(Double.parseDouble(range[0])); info.setMaxSalary(Double.parseDouble(range[1])); } else { double single Double.parseDouble(salaryStr); info.setMinSalary(single); info.setMaxSalary(single); } info.setMonths(months); return info; } }實(shí)際數(shù)據(jù)里還會(huì)遇到面議、薪資面議這種非數(shù)值的情況解析時(shí)要單獨(dú)處理標(biāo)記為未知或跳過。另外有些崗位標(biāo)注的是日薪或時(shí)薪單位不是K這些都要在解析邏輯里做兼容。4.3 技能標(biāo)簽的歸一化處理崗位的技能標(biāo)簽是最有價(jià)值的數(shù)據(jù)之一但不同公司寫的標(biāo)簽五花八門。同樣是Java開發(fā)有的寫Java有的寫JAVA有的寫java開發(fā)有的寫Java工程師。如果不做歸一化后續(xù)統(tǒng)計(jì)出來的結(jié)果會(huì)很亂。我的做法是維護(hù)一個(gè)映射表把常見變體映射到標(biāo)準(zhǔn)名稱MapString, String skillNormalizeMap new HashMap(); skillNormalizeMap.put(java, Java); skillNormalizeMap.put(JAVA, Java); skillNormalizeMap.put(spring, Spring); skillNormalizeMap.put(springboot, Spring Boot); skillNormalizeMap.put(spring boot, Spring Boot); skillNormalizeMap.put(mysql, MySQL); skillNormalizeMap.put(redis, Redis);歸一化之后再做詞頻統(tǒng)計(jì)結(jié)果就干凈多了。這個(gè)映射表需要根據(jù)實(shí)際采集到的數(shù)據(jù)不斷補(bǔ)充完善一開始不用追求大而全先覆蓋高頻技能即可。5. 反爬機(jī)制識(shí)別與應(yīng)對(duì)策略的完整排查鏈路5.1 從403到驗(yàn)證碼一次完整的踩坑記錄我第一次跑批量采集的時(shí)候前50個(gè)請(qǐng)求一切正常第51個(gè)開始全部返回403。當(dāng)時(shí)第一反應(yīng)是IP被封了換了代理繼續(xù)跑結(jié)果新IP跑了幾十個(gè)請(qǐng)求又被封。這說明不是IP的問題是請(qǐng)求特征被識(shí)別了。排查過程是這樣的先用單個(gè)請(qǐng)求手動(dòng)測(cè)試確認(rèn)請(qǐng)求頭和參數(shù)沒問題能正常返回?cái)?shù)據(jù)。然后逐步增加請(qǐng)求頻率發(fā)現(xiàn)當(dāng)QPS超過某個(gè)閾值時(shí)開始出現(xiàn)403。接著檢查響應(yīng)內(nèi)容發(fā)現(xiàn)403頁面里有一段JavaScript代碼是網(wǎng)站的反爬腳本在檢測(cè)瀏覽器環(huán)境。再進(jìn)一步分析發(fā)現(xiàn)網(wǎng)站還校驗(yàn)了Cookie中的某些字段這些字段是頁面加載時(shí)由JavaScript生成的。這個(gè)排查鏈路告訴我們反爬不是單一維度的而是多維度組合的。頻率限制、請(qǐng)求頭校驗(yàn)、Cookie校驗(yàn)、JavaScript挑戰(zhàn)可能同時(shí)存在。應(yīng)對(duì)策略也要分層頻率控制解決QPS問題請(qǐng)求頭偽裝解決特征識(shí)別問題Cookie維護(hù)解決會(huì)話校驗(yàn)問題。5.2 請(qǐng)求頻率控制的工程化實(shí)現(xiàn)控制頻率最粗暴的方式是Thread.sleep()但這樣會(huì)阻塞線程浪費(fèi)資源。更好的方式是用Guava的RateLimiter做令牌桶限流RateLimiter rateLimiter RateLimiter.create(2.0); // 每秒2個(gè)請(qǐng)求 public String fetchWithRateLimit(String url) { rateLimiter.acquire(); // 獲取令牌不夠就等待 return doFetch(url); }RateLimiter.create(2.0)表示每秒生成2個(gè)令牌acquire()會(huì)阻塞直到拿到令牌。這樣既能控制速率又不會(huì)像sleep那樣浪費(fèi)固定時(shí)間。實(shí)際采集時(shí)建議把QPS控制在1到3之間具體看目標(biāo)網(wǎng)站的容忍度。我一般會(huì)先小批量測(cè)試從QPS1開始逐步提高觀察什么時(shí)候開始出現(xiàn)異常響應(yīng)然后把生產(chǎn)環(huán)境的QPS設(shè)成臨界值的一半。5.3 Cookie的獲取與維護(hù)策略需要登錄態(tài)的接口Cookie是繞不過去的。獲取Cookie有兩種方式一是手動(dòng)登錄后從瀏覽器復(fù)制二是用程序模擬登錄流程自動(dòng)獲取。手動(dòng)方式簡(jiǎn)單但Cookie會(huì)過期適合短期采集自動(dòng)方式復(fù)雜但可持續(xù)適合長期運(yùn)行。手動(dòng)獲取的Cookie一般有效期幾小時(shí)到幾天過期后需要重新獲取。我的做法是把Cookie存在配置文件或數(shù)據(jù)庫里程序啟動(dòng)時(shí)加載運(yùn)行中檢測(cè)到401或403且確認(rèn)是Cookie過期導(dǎo)致的就發(fā)通知提醒更新。自動(dòng)登錄涉及模擬表單提交、處理驗(yàn)證碼等環(huán)節(jié)復(fù)雜度較高。如果目標(biāo)網(wǎng)站有驗(yàn)證碼還需要接入打碼服務(wù)或做OCR識(shí)別。這部分展開講篇幅太大這里只提一個(gè)思路用Selenium或Playwright驅(qū)動(dòng)真實(shí)瀏覽器完成登錄然后從瀏覽器上下文里提取Cookie再交給HttpClient使用。這樣既繞過了JavaScript加密的登錄參數(shù)又能拿到有效的會(huì)話憑證。5.4 遇到IP封禁時(shí)的應(yīng)急處理即使做了頻率控制長時(shí)間采集還是可能觸發(fā)IP封禁。封禁的表現(xiàn)通常是所有請(qǐng)求返回403或者返回一個(gè)特殊的驗(yàn)證頁面。這時(shí)候需要切換到備用IP。代理池的切換邏輯要做得平滑主IP被封后自動(dòng)從池中取下一個(gè)可用IP繼續(xù)未完成的任務(wù)。同時(shí)記錄被封的IP和封禁時(shí)間過一段時(shí)間后再檢測(cè)是否解封。如果所有IP都被封了程序應(yīng)該暫停并告警而不是繼續(xù)無效請(qǐng)求。public class ProxyManager { private BlockingQueueProxy availableProxies; private SetProxy bannedProxies; public Proxy getProxy() { Proxy proxy availableProxies.poll(); if (proxy null) { throw new RuntimeException(代理池已耗盡); } return proxy; } public void reportBanned(Proxy proxy) { bannedProxies.add(proxy); // 延遲后重新加入可用池 scheduledExecutor.schedule(() - { bannedProxies.remove(proxy); availableProxies.offer(proxy); }, 30, TimeUnit.MINUTES); } }6. 數(shù)據(jù)存儲(chǔ)方案選型與批量寫入優(yōu)化6.1 存文件還是存數(shù)據(jù)庫根據(jù)數(shù)據(jù)量做決定采集到的數(shù)據(jù)存哪里取決于數(shù)據(jù)量和使用場(chǎng)景。如果只是幾千條數(shù)據(jù)做一次性分析存CSV或JSON文件就夠了簡(jiǎn)單直接。如果要持續(xù)采集、數(shù)據(jù)量到幾十萬上百萬條或者需要頻繁查詢和關(guān)聯(lián)分析那就得上數(shù)據(jù)庫。我的建議是采集階段先落地到文件JSON Lines格式每行一個(gè)JSON對(duì)象這樣即使程序崩潰也不會(huì)丟數(shù)據(jù)而且方便排查問題。采集完成后再批量導(dǎo)入數(shù)據(jù)庫做后續(xù)處理。JSON Lines的好處是追加寫入方便不需要讀取整個(gè)文件再修改。public void saveToFile(JobInfo job, String filePath) { try (BufferedWriter writer new BufferedWriter( new FileWriter(filePath, true))) { ObjectMapper mapper new ObjectMapper(); writer.write(mapper.writeValueAsString(job)); writer.newLine(); } catch (IOException e) { log.error(寫入文件失敗, e); } }6.2 MySQL表結(jié)構(gòu)設(shè)計(jì)與索引優(yōu)化如果選擇MySQL存儲(chǔ)表結(jié)構(gòu)設(shè)計(jì)要考慮查詢場(chǎng)景。崗位信息表的核心字段包括崗位ID唯一標(biāo)識(shí)、崗位名稱、公司名稱、薪資范圍、城市、經(jīng)驗(yàn)要求、學(xué)歷要求、技能標(biāo)簽、采集時(shí)間。CREATE TABLE job_info ( id BIGINT AUTO_INCREMENT PRIMARY KEY, job_id VARCHAR(64) NOT NULL COMMENT 崗位唯一標(biāo)識(shí), job_name VARCHAR(128) NOT NULL COMMENT 崗位名稱, company_name VARCHAR(128) COMMENT 公司名稱, salary_min DECIMAL(10,2) COMMENT 最低薪資(K), salary_max DECIMAL(10,2) COMMENT 最高薪資(K), salary_months INT DEFAULT 12 COMMENT 薪資月數(shù), city VARCHAR(32) COMMENT 城市, experience VARCHAR(32) COMMENT 經(jīng)驗(yàn)要求, degree VARCHAR(32) COMMENT 學(xué)歷要求, skills VARCHAR(512) COMMENT 技能標(biāo)簽逗號(hào)分隔, crawl_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 采集時(shí)間, UNIQUE KEY uk_job_id (job_id), INDEX idx_city (city), INDEX idx_job_name (job_name), INDEX idx_crawl_time (crawl_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;job_id上建唯一索引是為了去重重復(fù)采集時(shí)用INSERT IGNORE或ON DUPLICATE KEY UPDATE避免重復(fù)插入。city和job_name上建普通索引是為了加速按城市和崗位名稱的查詢。crawl_time索引用于按時(shí)間范圍篩選。6.3 批量插入的性能對(duì)比實(shí)測(cè)逐條INSERT在數(shù)據(jù)量大時(shí)性能很差每條都要走一次網(wǎng)絡(luò)往返和事務(wù)提交。批量插入能顯著提升吞吐量。我實(shí)測(cè)過三種方式的性能差異插入方式1萬條耗時(shí)說明逐條INSERT約45秒每條一個(gè)事務(wù)批量INSERT500條一批約3秒需設(shè)置rewriteBatchedStatementstrueLOAD DATA INFILE約1秒需要文件權(quán)限適合超大批量批量插入的關(guān)鍵是在JDBC URL里加上rewriteBatchedStatementstrue否則MySQL驅(qū)動(dòng)不會(huì)真正合并SQL語句。代碼層面用addBatch()和executeBatch()String sql INSERT INTO job_info (job_id, job_name, company_name, salary_min, salary_max, city, experience, degree, skills) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?); try (PreparedStatement pstmt conn.prepareStatement(sql)) { conn.setAutoCommit(false); int count 0; for (JobInfo job : jobList) { pstmt.setString(1, job.getJobId()); pstmt.setString(2, job.getJobName()); // ... 設(shè)置其他參數(shù) pstmt.addBatch(); if (count % 500 0) { pstmt.executeBatch(); conn.commit(); } } pstmt.executeBatch(); conn.commit(); }注意批量插入時(shí)如果某條數(shù)據(jù)違反唯一約束整個(gè)批次可能失敗。用INSERT IGNORE可以跳過重復(fù)數(shù)據(jù)但會(huì)忽略其他錯(cuò)誤。更穩(wěn)妥的做法是先用SELECT查出已存在的job_id過濾后再批量插入。7. 并發(fā)采集的線程模型與任務(wù)調(diào)度設(shè)計(jì)7.1 用線程池管理采集任務(wù)單線程采集太慢假設(shè)每個(gè)請(qǐng)求耗時(shí)500毫秒采集1萬條數(shù)據(jù)需要5000秒將近一個(gè)半小時(shí)。用10個(gè)線程并發(fā)理論上能壓縮到9分鐘左右。但線程不是越多越好太多線程會(huì)導(dǎo)致請(qǐng)求頻率過高觸發(fā)風(fēng)控也會(huì)增加上下文切換開銷。我的經(jīng)驗(yàn)是線程數(shù)控制在5到10之間配合RateLimiter做全局限流。線程池用ThreadPoolExecutor手動(dòng)創(chuàng)建不要用Executors.newFixedThreadPool()因?yàn)楹笳哂玫氖菬o界隊(duì)列任務(wù)積壓時(shí)可能OOM。ThreadPoolExecutor executor new ThreadPoolExecutor( 5, // 核心線程數(shù) 10, // 最大線程數(shù) 60L, TimeUnit.SECONDS, // 空閑線程存活時(shí)間 new LinkedBlockingQueue(1000), // 有界隊(duì)列 new ThreadFactoryBuilder().setNameFormat(crawler-%d).build(), new ThreadPoolExecutor.CallerRunsPolicy() // 拒絕策略 );CallerRunsPolicy表示隊(duì)列滿了之后由提交任務(wù)的線程自己執(zhí)行這樣能起到背壓作用防止任務(wù)無限堆積。7.2 分頁任務(wù)的拆分與結(jié)果聚合采集任務(wù)可以按頁碼拆分每個(gè)線程負(fù)責(zé)若干頁。比如總共100頁10個(gè)線程每個(gè)線程負(fù)責(zé)10頁。但要注意頁碼的分配要考慮請(qǐng)求間隔不能讓所有線程同時(shí)請(qǐng)求相鄰頁那樣請(qǐng)求特征太明顯。更好的方式是用一個(gè)共享的AtomicInteger作為頁碼計(jì)數(shù)器每個(gè)線程從計(jì)數(shù)器里取下一頁的頁碼取完就加一。這樣線程之間自然錯(cuò)開不會(huì)重復(fù)采集同一頁。AtomicInteger pageCounter new AtomicInteger(1); int totalPages 100; Runnable task () - { while (true) { int page pageCounter.getAndIncrement(); if (page totalPages) { break; } try { ListJobInfo jobs fetchPage(page); saveJobs(jobs); } catch (Exception e) { log.error(采集第{}頁失敗, page, e); } } };結(jié)果聚合方面每個(gè)線程采集到的數(shù)據(jù)先存到線程本地的List里最后統(tǒng)一匯總?；蛘咧苯佑镁€程安全的ConcurrentLinkedQueue收集避免鎖競(jìng)爭(zhēng)。7.3 采集進(jìn)度的監(jiān)控與斷點(diǎn)續(xù)傳長時(shí)間運(yùn)行的采集任務(wù)需要進(jìn)度監(jiān)控否則你不知道跑到哪了、還剩多少、有沒有卡住。簡(jiǎn)單的做法是每完成一頁就打印日志記錄當(dāng)前頁碼和已采集數(shù)量。更完善的做法是用AtomicLong統(tǒng)計(jì)成功和失敗的數(shù)量定期輸出統(tǒng)計(jì)信息。斷點(diǎn)續(xù)傳是另一個(gè)實(shí)用功能。程序意外中斷后重新啟動(dòng)時(shí)能從上次中斷的頁碼繼續(xù)而不是從頭再來。實(shí)現(xiàn)方式是把已完成的頁碼記錄到文件或Redis里啟動(dòng)時(shí)讀取并跳過這些頁碼。public class ProgressTracker { private SetInteger completedPages new HashSet(); private String progressFile progress.txt; public void load() { // 從文件加載已完成的頁碼 try (BufferedReader reader new BufferedReader(new FileReader(progressFile))) { String line; while ((line reader.readLine()) ! null) { completedPages.add(Integer.parseInt(line.trim())); } } catch (IOException e) { // 文件不存在則忽略 } } public void markCompleted(int page) { completedPages.add(page); // 追加寫入文件 try (BufferedWriter writer new BufferedWriter(new FileWriter(progressFile, true))) { writer.write(String.valueOf(page)); writer.newLine(); } catch (IOException e) { log.error(記錄進(jìn)度失敗, e); } } public boolean isCompleted(int page) { return completedPages.contains(page); } }8. 采集過程中的幾個(gè)實(shí)用技巧與避坑經(jīng)驗(yàn)8.1 請(qǐng)求間隔的隨機(jī)化處理固定間隔的請(qǐng)求模式很容易被識(shí)別。比如你每隔1秒發(fā)一個(gè)請(qǐng)求連續(xù)發(fā)100個(gè)這個(gè)模式太規(guī)律了風(fēng)控系統(tǒng)一眼就能看出來。解決辦法是在基礎(chǔ)間隔上疊加隨機(jī)抖動(dòng)public void randomDelay() { // 基礎(chǔ)間隔1000ms隨機(jī)浮動(dòng)500ms long delay 1000 (long)(Math.random() * 500); try { Thread.sleep(delay); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } }這樣請(qǐng)求間隔在1000到1500毫秒之間隨機(jī)分布看起來更像人工操作。如果配合RateLimiter使用可以把RateLimiter的速率設(shè)得稍高一些然后用隨機(jī)延遲做二次控制。8.2 響應(yīng)內(nèi)容的編碼問題中文網(wǎng)站經(jīng)常遇到編碼問題返回的JSON里中文變成亂碼。原因是服務(wù)器返回的Content-Type里聲明的編碼和實(shí)際編碼不一致或者HttpClient沒有正確識(shí)別。解決辦法是手動(dòng)指定編碼String responseBody EntityUtils.toString(entity, StandardCharsets.UTF_8);如果UTF-8還是亂碼試試GBK。有些老網(wǎng)站用的是GB2312或GBK編碼?？梢栽陧憫?yīng)頭里看Content-Type字段的charset值按那個(gè)來設(shè)置。8.3 日志記錄的分級(jí)與脫敏采集程序的日志要分級(jí)記錄INFO級(jí)別記錄每頁的采集結(jié)果WARN級(jí)別記錄重試和異常ERROR級(jí)別記錄失敗和需要人工介入的問題。日志里不要打印完整的Cookie和請(qǐng)求頭這些包含敏感信息泄露出去有安全風(fēng)險(xiǎn)。log.info(第{}頁采集完成獲取{}條數(shù)據(jù), page, jobs.size()); log.warn(第{}頁請(qǐng)求失敗準(zhǔn)備第{}次重試, page, retryCount); log.error(第{}頁采集失敗已重試{}次, page, maxRetry);8.4 數(shù)據(jù)去重的時(shí)機(jī)與策略去重可以在三個(gè)環(huán)節(jié)做采集時(shí)去重、入庫時(shí)去重、分析時(shí)去重。采集時(shí)去重最省資源但需要維護(hù)一個(gè)已采集ID的集合內(nèi)存占用隨數(shù)據(jù)量增長。入庫時(shí)去重用數(shù)據(jù)庫唯一索引簡(jiǎn)單可靠但會(huì)增加數(shù)據(jù)庫壓力。分析時(shí)去重最靈活但每次分析都要處理重復(fù)數(shù)據(jù)。我的建議是入庫時(shí)去重為主采集時(shí)去重為輔。采集時(shí)用一個(gè)布隆過濾器或Redis Set記錄已采集的job_id快速判斷是否重復(fù)入庫時(shí)用唯一索引兜底確保最終數(shù)據(jù)不重復(fù)。// 用Redis Set做采集時(shí)去重 public boolean isDuplicate(String jobId) { Boolean added redisTemplate.opsForSet().add(crawled_job_ids, jobId); return added null || !added; }8.5 異常情況的兜底處理采集過程中會(huì)遇到各種異常網(wǎng)絡(luò)超時(shí)、JSON解析失敗、字段缺失、數(shù)據(jù)庫連接斷開。每個(gè)環(huán)節(jié)都要有兜底處理不能讓一個(gè)異常導(dǎo)致整個(gè)程序崩潰。網(wǎng)絡(luò)異常用重試機(jī)制處理重試多次仍失敗則記錄到失敗隊(duì)列后續(xù)單獨(dú)處理。JSON解析失敗通常是接口結(jié)構(gòu)變了這時(shí)候要記錄原始響應(yīng)內(nèi)容方便排查。字段缺失用默認(rèn)值填充不要拋異常。數(shù)據(jù)庫連接斷開用連接池自動(dòng)重連或者捕獲異常后重新獲取連接。try { ListJobInfo jobs parseResponse(responseBody); saveToDatabase(jobs); } catch (JsonParseException e) { log.error(JSON解析失敗原始響應(yīng){}, responseBody, e); saveFailedRecord(responseBody); } catch (SQLException e) { log.error(數(shù)據(jù)庫寫入失敗, e); saveToFile(jobs); // 降級(jí)到文件存儲(chǔ) }這套采集方案我在幾個(gè)內(nèi)部項(xiàng)目里跑過單機(jī)每天穩(wěn)定采集幾萬條數(shù)據(jù)沒有問題。核心不在于代碼寫得多復(fù)雜而在于對(duì)目標(biāo)網(wǎng)站的理解夠不夠深、對(duì)異常情況的考慮夠不夠全。先把請(qǐng)求鏈路摸清楚再把反爬策略研究透最后把工程細(xì)節(jié)做扎實(shí)剩下的就是耐心跑數(shù)據(jù)了。