NodeJs爬蟲抓取古代典籍，共計16000個頁面心得體會總結

02-17

前言

之前研究數據，零零散散的寫過一些數據抓取的爬蟲，不過寫的比較隨意。有很多地方現在看起來並不是很合理這段時間比較閑，本來是想給之前的項目做重構的。

後來利用這個周末，索性重新寫了一個項目，就是本項目 guwen-spider。目前這個爬蟲還是比較簡單的類型的，直接抓取頁面，然後在頁面中提取數據，保存數據到資料庫。

通過與之前寫的對比，我覺得難點在於整個程序的健壯性，以及相應的容錯機制。在昨天寫代碼的過程中其實也有反映，真正的主體代碼其實很快就寫完了，花了大部分時間是在

做穩定性的調試，以及尋求一種更合理的方式來處理數據與流程式控制制的關係。

背景

項目的背景是抓取一個一級頁面是目錄列表，點擊一個目錄進去是一個章節及篇幅列表，點擊章節或篇幅進入具體的內容頁面。

概述

本項目github地址 : [guwen-spider](yangfan0095/guwen-spider) （PS:最後面還有彩蛋 ~~逃

項目技術細節

項目大量用到了 ES7 的async 函數, 更直觀的反應程序了的流程。為了方便，在對數據遍歷的過程中直接使用了著名的async這個庫，所以不可避免的還是用到了回調promise ，因為數據的處理髮生在回調函數中，不可避免的會遇到一些數據傳遞的問題，其實也可以直接用ES7的async await 寫一個方法來實現相同的功能。這裡其實最贊的一個地方是使用了 Class 的 static 方法封裝對資料庫的操作， static 顧名思義靜態方法就跟 prototype 一樣，不會佔用額外空間。

項目主要用到了

* 1 ES7的 async await 協程做非同步有關的邏輯處理。

* 2 使用 npm的 async庫來做循環遍歷，以及並發請求操作。

* 3 使用 log4js 來做日誌處理

* 4 使用 cheerio 來處理dom的操作。

* 5 使用 mongoose 來連接mongoDB 做數據的保存以及操作。

目錄結構

├── bin // 入口

│ ├── booklist.js // 抓取書籍邏輯

│ ├── chapterlist.js // 抓取章節邏輯

│ ├── content.js // 抓取內容邏輯

│ └── index.js // 程序入口

├── config // 配置文件

├── dbhelper // 資料庫操作方法目錄

├── logs // 項目日誌目錄

├── model // mongoDB 集合操作實例

├── node_modules

├── utils // 工具函數

├── package.json

項目實現方案分析

項目是一個典型的多級抓取案例，目前只有三級，即書籍列表，書籍項對應的章節列表，一個章節鏈接對應的內容。抓取這樣的結構可以採用兩種方式，一是直接從外層到內層內層抓取完以後再執行下一個外層的抓取，還有一種就是先把外層抓取完成保存到資料庫，然後根據外層抓取到所有內層章節的鏈接，再次保存，然後從資料庫查詢到對應的鏈接單元對之進行內容抓取。這兩種方案各有利弊，其實兩種方式我都試過，後者有一個好處，因為對三個層級是分開抓取的，這樣就能夠更方便，儘可能多的保存到對應章節的相關數據。可以試想一下，如果採用前者按照正常的邏輯

對一級目錄進行遍歷抓取到對應的二級章節目錄，再對章節列表進行遍歷抓取內容，到第三級內容單元抓取完成需要保存時，如果需要很多的一級目錄信息，就需要這些分層的數據之間進行數據傳遞，想想其實應該是比較複雜的一件事情。所以分開保存數據一定程度上避開了不必要的複雜的數據傳遞。

目前我們考慮到其實我們要抓取到的古文書籍數量並不多，古文書籍大概只有180本囊括了各種經史。其和章節內容本身是一個很小的數據，即一個集合裡面有180個文檔記錄。這180本書所有章節抓取下來一共有一萬六千個章節，對應需要訪問一萬六千個頁面爬取到對應的內容。所以選擇第二種應該是合理的。

項目實現

主程有三個方法 bookListInit ,chapterListInit,contentListInit, 分別是抓取書籍目錄，章節列表，書籍內容的方法對外公開暴露的初始化方法。通過async 可以實現對這三個方法的運行流程進行控制，書籍目錄抓取完成將數據保存到資料庫，然後執行結果返回到主程序，如果運行成功主程序則執行根據書籍列表對章節列表的抓取，同理對書籍內容進行抓取。

項目主入口

/*** 爬蟲抓取主入口*/const start = async() => { let booklistRes = await bookListInit(); if (!booklistRes) { logger.warn(書籍列表抓取出錯，程序終止...); return; }logger.info(書籍列表抓取成功，現在進行書籍章節抓取...); let chapterlistRes = await chapterListInit(); if (!chapterlistRes) { logger.warn(書籍章節列表抓取出錯，程序終止...); return; }logger.info(書籍章節列表抓取成功，現在進行書籍內容抓取...); let contentListRes = await contentListInit(); if (!contentListRes) { logger.warn(書籍章節內容抓取出錯，程序終止...); return; }logger.info(書籍內容抓取成功);}// 開始入口if (typeof bookListInit === function && typeof chapterListInit === function) { // 開始抓取 start();}

引入的 bookListInit ,chapterListInit,contentListInit, 三個方法

booklist.js

/*** 初始化方法返回抓取結果 true 抓取成果 false 抓取失敗*/const bookListInit = async() => {logger.info(抓取書籍列表開始...); const pageUrlList = getPageUrlList(totalListPage, baseUrl); let res = await getBookList(pageUrlList); return res;}

chapterlist.js

/*** 初始化入口*/const chapterListInit = async() => { const list = await bookHelper.getBookList(bookListModel); if (!list) { logger.error(初始化查詢書籍目錄失敗); }logger.info(開始抓取書籍章節列表，書籍目錄共： + list.length + 條); let res = await asyncGetChapter(list); return res;};

content.js

/*** 初始化入口*/const contentListInit = async() => { //獲取書籍列表 const list = await bookHelper.getBookLi(bookListModel); if (!list) { logger.error(初始化查詢書籍目錄失敗); return; } const res = await mapBookList(list); if (!res) { logger.error(抓取章節信息，調用 getCurBookSectionList() 進行串列遍歷操作，執行完成回調出錯，錯誤信息已列印，請查看日誌!); return; } return res;}

內容抓取的思考

書籍目錄抓取其實邏輯非常簡單，只需要使用async.mapLimit做一個遍歷就可以保存數據了,但是我們在保存內容的時候簡化的邏輯其實就是遍歷章節列表抓取鏈接里的內容。但是實際的情況是鏈接數量多達幾萬我們從內存佔用角度也不能全部保存到一個數組中，然後對其遍歷，所以我們需要對內容抓取進行單元化。

普遍的遍歷方式是每次查詢一定的數量，來做抓取，這樣缺點是只是以一定數量做分類，數據之間沒有關聯，以批量方式進行插入，如果出錯則容錯會有一些小問題，而且我們想一本書作為一個集合單獨保存會遇到問題。因此我們採用第二種就是以一個書籍單元進行內容抓取和保存。

這裡使用了 `async.mapLimit(list, 1, (series, callback) => {})`這個方法來進行遍歷，不可避免的用到了回調，感覺很噁心。async.mapLimit()的第二個參數可以設置同時請求數量。

/* * 內容抓取步驟：* 第一步得到書籍列表，通過書籍列表查到一條書籍記錄下對應的所有章節列表， * 第二步對章節列表進行遍歷獲取內容保存到資料庫中 * 第三步保存完數據後回到第一步進行下一步書籍的內容抓取和保存*//*** 初始化入口*/const contentListInit = async() => { //獲取書籍列表 const list = await bookHelper.getBookList(bookListModel); if (!list) { logger.error(初始化查詢書籍目錄失敗); return; } const res = await mapBookList(list); if (!res) { logger.error(抓取章節信息，調用 getCurBookSectionList() 進行串列遍歷操作，執行完成回調出錯，錯誤信息已列印，請查看日誌!); return; } return res;}/*** 遍曆書籍目錄下的章節列表* @param {*} list */const mapBookList = (list) => { return new Promise((resolve, reject) => { async.mapLimit(list, 1, (series, callback) => { let doc = series._doc; getCurBookSectionList(doc, callback); }, (err, result) => { if (err) { logger.error(書籍目錄抓取非同步執行出錯!); logger.error(err); reject(false); return; } resolve(true); }) })}/*** 獲取單本書籍下章節列表調用章節列表遍歷進行抓取內容* @param {*} series * @param {*} callback */const getCurBookSectionList = async(series, callback) => { let num = Math.random() * 1000 + 1000; await sleep(num); let key = series.key; const res = await bookHelper.querySectionList(chapterListModel, { key: key }); if (!res) { logger.error(獲取當前書籍: + series.bookName + 章節內容失敗，進入下一部書籍內容抓取!); callback(null, null); return; } //判斷當前數據是否已經存在 const bookItemModel = getModel(key); const contentLength = await bookHelper.getCollectionLength(bookItemModel, {}); if (contentLength === res.length) {logger.info(當前書籍： + series.bookName + 資料庫已經抓取完成，進入下一條數據任務); callback(null, null); return; } await mapSectionList(res); callback(null, null);}

數據抓取完了怎麼保存是個問題

這裡我們通過key 來給數據做分類，每次按照key來獲取鏈接，進行遍歷，這樣的好處是保存的數據是一個整體，現在思考數據保存的問題

1 可以以整體的方式進行插入

優點 : 速度快資料庫操作不浪費時間。

缺點 : 有的書籍可能有幾百個章節也就意味著要先保存幾百個頁面的內容再進行插入，這樣做同樣很消耗內存，有可能造成程序運行不穩定。

2可以以每一篇文章的形式插入資料庫。

優點 : 頁面抓取即保存的方式使得數據能夠及時保存，即使後續出錯也不需要重新保存前面的章節，

缺點 : 也很明顯就是慢，仔細想想如果要爬幾萬個頁面做幾萬次*N 資料庫的操作這裡還可以做一個緩存器一次性保存一定條數當條數達到再做保存這樣也是一個不錯的選擇。

/*** 遍歷單條書籍下所有章節調用內容抓取方法* @param {*} list */const mapSectionList = (list) => { return new Promise((resolve, reject) => { async.mapLimit(list, 1, (series, callback) => { let doc = series._doc; getContent(doc, callback) }, (err, result) => { if (err) { logger.error(書籍目錄抓取非同步執行出錯!); logger.error(err); reject(false); return; } const bookName = list[0].bookName; const key = list[0].key; // 以整體為單元進行保存 saveAllContentToDB(result, bookName, key, resolve); //以每篇文章作為單元進行保存 // logger.info(bookName + 數據抓取完成，進入下一部書籍抓取函數...); // resolve(true); }) })}

兩者各有利弊，這裡我們都做了嘗試。準備了兩個錯誤保存的集合,errContentModel, errorCollectionModel,在插入出錯時分別保存信息到對應的集合中，二者任選其一即可。增加集合來保存數據的原因是便於一次性查看以及後續操作，不用看日誌。

（PS ，其實完全用 errorCollectionModel 這個集合就可以了，errContentModel這個集合可以完整保存章節信息）

//保存出錯的數據名稱const errorSpider = mongoose.Schema({ chapter: String, section: String, url: String, key: String, bookName: String, author: String,})// 保存出錯的數據名稱只保留key 和 bookName信息const errorCollection = mongoose.Schema({ key: String, bookName: String,})

我們將每一條書籍信息的內容放到一個新的集合中，集合以key來進行命名。

總結

寫這個項目其實主要的難點在於程序穩定性的控制，容錯機制的設置，以及錯誤的記錄，目前這個項目基本能夠實現直接運行一次性跑通整個流程。但是程序設計也肯定還存在許多問題，歡迎指正和交流。

彩蛋

寫完這個項目做了一個基於React開的前端網站用於頁面瀏覽和一個基於koa2.x開發的服務端, 整體技術棧相當於是 React + Redux + Koa2 ,前後端服務是分開部署的，各自獨立可以更好的去除前後端服務的耦合性，比如同一套服務端代碼，不僅可以給web端還可以給移動端，app 提供支持。目前整個一套還很簡陋，但是可以滿足基本的查詢瀏覽功能。希望後期有時間可以把項目變得更加豐富。

本項目地址地址 : [guwen-spider](yangfan0095/guwen-spider)

對應前端 React + Redux + semantic-ui 地址 : [guwen-react](yangfan0095/guwen-react)

對應Node端 Koa2.2 + mongoose 地址 : [guwen-node](yangfan0095/guwen-node)

項目挺簡單的，但是多了一個學習和研究從前端到服務端的開發的環境。

感謝閱讀!

以上です