摘要：目前這個(gè)爬蟲還是比較簡單的類型的，直接抓取頁面，然后在頁面中提取數(shù)據(jù)，保存數(shù)據(jù)到數(shù)據(jù)庫?？偨Y(jié)寫這個(gè)項(xiàng)目其實(shí)主要的難點(diǎn)在于程序穩(wěn)定性的控制，容錯(cuò)機(jī)制的設(shè)置，以及錯(cuò)誤的記錄，目前這個(gè)項(xiàng)目基本能夠?qū)崿F(xiàn)直接運(yùn)行一次性跑通整個(gè)流程。

之前研究數(shù)據(jù)，零零散散的寫過一些數(shù)據(jù)抓取的爬蟲，不過寫的比較隨意。有很多地方現(xiàn)在看起來并不是很合理 這段時(shí)間比較閑，本來是想給之前的項(xiàng)目做重構(gòu)的。
后來 利用這個(gè)周末，索性重新寫了一個(gè)項(xiàng)目，就是本項(xiàng)目 guwen-spider。目前這個(gè)爬蟲還是比較簡單的類型的， 直接抓取頁面，然后在頁面中提取數(shù)據(jù)，保存數(shù)據(jù)到數(shù)據(jù)庫。
通過與之前寫的對(duì)比，我覺得難點(diǎn)在于整個(gè)程序的健壯性，以及相應(yīng)的容錯(cuò)機(jī)制。在昨天寫代碼的過程中其實(shí)也有反映， 真正的主體代碼其實(shí)很快就寫完了 ，花了大部分時(shí)間是在
做穩(wěn)定性的調(diào)試， 以及尋求一種更合理的方式來處理數(shù)據(jù)與流程控制的關(guān)系。

項(xiàng)目的背景是抓取一個(gè)一級(jí)頁面是目錄列表 ，點(diǎn)擊一個(gè)目錄進(jìn)去 是一個(gè)章節(jié) 及篇幅列表 ，點(diǎn)擊章節(jié)或篇幅進(jìn)入具體的內(nèi)容頁面。

本項(xiàng)目github地址 : guwen-spider （PS:最后面還有彩蛋 ~~逃

項(xiàng)目技術(shù)細(xì)節(jié)
項(xiàng)目大量用到了 ES7 的async 函數(shù), 更直觀的反應(yīng)程序了的流程。為了方便，在對(duì)數(shù)據(jù)遍歷的過程中直接使用了著名的async這個(gè)庫，所以不可避免的還是用到了回調(diào)promise ，因?yàn)閿?shù)據(jù)的處理發(fā)生在回調(diào)函數(shù)中，不可避免的會(huì)遇到一些數(shù)據(jù)傳遞的問題，其實(shí)也可以直接用ES7的async await 寫一個(gè)方法來實(shí)現(xiàn)相同的功能。這里其實(shí)最贊的一個(gè)地方是使用了 Class 的 static 方法封裝對(duì)數(shù)據(jù)庫的操作， static 顧名思義 靜態(tài)方法 就跟 prototype 一樣 ，不會(huì)占用額外空間。
項(xiàng)目主要用到了

1 ES7的 async await 協(xié)程做異步有關(guān)的邏輯處理。

2 使用 npm的 async庫 來做循環(huán)遍歷，以及并發(fā)請(qǐng)求操作。

3 使用 log4js 來做日志處理

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

5 使用 mongoose 來連接mongoDB 做數(shù)據(jù)的保存以及操作。

目錄結(jié)構(gòu)

├── bin              // 入口
│?  ├── booklist.js         // 抓取書籍邏輯
│?  ├── chapterlist.js      // 抓取章節(jié)邏輯
│?  ├── content.js          // 抓取內(nèi)容邏輯
│?  └── index.js            // 程序入口
├── config             // 配置文件
├── dbhelper           // 數(shù)據(jù)庫操作方法目錄
├── logs             // 項(xiàng)目日志目錄
├── model         // mongoDB 集合操作實(shí)例
├── node_modules         
├── utils         // 工具函數(shù)
├── package.json       

項(xiàng)目實(shí)現(xiàn)方案分析

項(xiàng)目是一個(gè)典型的多級(jí)抓取案例，目前只有三級(jí)，即 書籍列表， 書籍項(xiàng)對(duì)應(yīng)的 章節(jié)列表，一個(gè)章節(jié)鏈接對(duì)應(yīng)的內(nèi)容。 抓取這樣的結(jié)構(gòu)可以采用兩種方式， 一是 直接從外層到內(nèi)層 內(nèi)層抓取完以后再執(zhí)行下一個(gè)外層的抓取， 還有一種就是先把外層抓取完成保存到數(shù)據(jù)庫，然后根據(jù)外層抓取到所有內(nèi)層章節(jié)的鏈接，再次保存，然后從數(shù)據(jù)庫查詢到對(duì)應(yīng)的鏈接單元 對(duì)之進(jìn)行內(nèi)容抓取。這兩種方案各有利弊，其實(shí)兩種方式我都試過， 后者有一個(gè)好處，因?yàn)閷?duì)三個(gè)層級(jí)是分開抓取的， 這樣就能夠更方便，盡可能多的保存到對(duì)應(yīng)章節(jié)的相關(guān)數(shù)據(jù)。 可以試想一下 ，如果采用前者 按照正常的邏輯
對(duì)一級(jí)目錄進(jìn)行遍歷抓取到對(duì)應(yīng)的二級(jí)章節(jié)目錄， 再對(duì)章節(jié)列表進(jìn)行遍歷 抓取內(nèi)容，到第三級(jí) 內(nèi)容單元抓取完成 需要保存時(shí)，如果需要很多的一級(jí)目錄信息，就需要 這些分層的數(shù)據(jù)之間進(jìn)行數(shù)據(jù)傳遞 ，想想其實(shí)應(yīng)該是比較復(fù)雜的一件事情。所以分開保存數(shù)據(jù) 一定程度上避開了不必要的復(fù)雜的數(shù)據(jù)傳遞。

目前我們考慮到 其實(shí)我們要抓取到的古文書籍?dāng)?shù)量并不多，古文書籍大概只有180本囊括了各種經(jīng)史。其和章節(jié)內(nèi)容本身是一個(gè)很小的數(shù)據(jù) ，即一個(gè)集合里面有180個(gè)文檔記錄。 這180本書所有章節(jié)抓取下來一共有一萬六千個(gè)章節(jié)，對(duì)應(yīng)需要訪問一萬六千個(gè)頁面爬取到對(duì)應(yīng)的內(nèi)容。所以選擇第二種應(yīng)該是合理的。

項(xiàng)目實(shí)現(xiàn)

主程有三個(gè)方法 bookListInit ,chapterListInit,contentListInit, 分別是抓取書籍目錄，章節(jié)列表，書籍內(nèi)容的方法對(duì)外公開暴露的初始化方法。通過async 可以實(shí)現(xiàn)對(duì)這三個(gè)方法的運(yùn)行流程進(jìn)行控制，書籍目錄抓取完成將數(shù)據(jù)保存到數(shù)據(jù)庫，然后執(zhí)行結(jié)果返回到主程序，如果運(yùn)行成功 主程序則執(zhí)行根據(jù)書籍列表對(duì)章節(jié)列表的抓取，同理對(duì)書籍內(nèi)容進(jìn)行抓取。

項(xiàng)目主入口

/**
 * 爬蟲抓取主入口
 */
const start = async() => {
    let booklistRes = await bookListInit();
    if (!booklistRes) {
        logger.warn("書籍列表抓取出錯(cuò)，程序終止...");
        return;
    }
    logger.info("書籍列表抓取成功，現(xiàn)在進(jìn)行書籍章節(jié)抓取...");

    let chapterlistRes = await chapterListInit();
    if (!chapterlistRes) {
        logger.warn("書籍章節(jié)列表抓取出錯(cuò)，程序終止...");
        return;
    }
    logger.info("書籍章節(jié)列表抓取成功，現(xiàn)在進(jìn)行書籍內(nèi)容抓取...");

    let contentListRes = await contentListInit();
    if (!contentListRes) {
        logger.warn("書籍章節(jié)內(nèi)容抓取出錯(cuò)，程序終止...");
        return;
    }
    logger.info("書籍內(nèi)容抓取成功");
}
// 開始入口
if (typeof bookListInit === "function" && typeof chapterListInit === "function") {
    // 開始抓取
    start();
}

引入的 bookListInit ,chapterListInit,contentListInit, 三個(gè)方法

booklist.js

/**
 * 初始化方法 返回抓取結(jié)果 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("開始抓取書籍章節(jié)列表，書籍目錄共：" + 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("抓取章節(jié)信息，調(diào)用 getCurBookSectionList() 進(jìn)行串行遍歷操作，執(zhí)行完成回調(diào)出錯(cuò)，錯(cuò)誤信息已打印，請(qǐng)查看日志!");
        return;
    }
    return res;
}

內(nèi)容抓取的思考

書籍目錄抓取其實(shí)邏輯非常簡單，只需要使用async.mapLimit做一個(gè)遍歷就可以保存數(shù)據(jù)了,但是我們在保存內(nèi)容的時(shí)候 簡化的邏輯其實(shí)就是 遍歷章節(jié)列表 抓取鏈接里的內(nèi)容。但是實(shí)際的情況是鏈接數(shù)量多達(dá)幾萬 我們從內(nèi)存占用角度也不能全部保存到一個(gè)數(shù)組中，然后對(duì)其遍歷，所以我們需要對(duì)內(nèi)容抓取進(jìn)行單元化。
普遍的遍歷方式 是每次查詢一定的數(shù)量，來做抓取，這樣缺點(diǎn)是只是以一定數(shù)量做分類，數(shù)據(jù)之間沒有關(guān)聯(lián)，以批量方式進(jìn)行插入，如果出錯(cuò) 則容錯(cuò)會(huì)有一些小問題，而且我們想一本書作為一個(gè)集合多帶帶保存會(huì)遇到問題。因此我們采用第二種就是以一個(gè)書籍單元進(jìn)行內(nèi)容抓取和保存。
這里使用了 async.mapLimit(list, 1, (series, callback) => {})這個(gè)方法來進(jìn)行遍歷，不可避免的用到了回調(diào)，感覺很惡心。async.mapLimit()的第二個(gè)參數(shù)可以設(shè)置同時(shí)請(qǐng)求數(shù)量。

 /* 
 * 內(nèi)容抓取步驟：
 * 第一步得到書籍列表， 通過書籍列表查到一條書籍記錄下 對(duì)應(yīng)的所有章節(jié)列表， 
 * 第二步 對(duì)章節(jié)列表進(jìn)行遍歷獲取內(nèi)容保存到數(shù)據(jù)庫中 
 * 第三步 保存完數(shù)據(jù)后 回到第一步 進(jìn)行下一步書籍的內(nèi)容抓取和保存
 */

/**
 * 初始化入口
 */
const contentListInit = async() => {
    //獲取書籍列表
    const list = await bookHelper.getBookList(bookListModel);
    if (!list) {
        logger.error("初始化查詢書籍目錄失敗");
        return;
    }
    const res = await mapBookList(list);
    if (!res) {
        logger.error("抓取章節(jié)信息，調(diào)用 getCurBookSectionList() 進(jìn)行串行遍歷操作，執(zhí)行完成回調(diào)出錯(cuò)，錯(cuò)誤信息已打印，請(qǐng)查看日志!");
        return;
    }
    return res;
}
/**
 * 遍歷書籍目錄下的章節(jié)列表
 * @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("書籍目錄抓取異步執(zhí)行出錯(cuò)!");
                logger.error(err);
                reject(false);
                return;
            }
            resolve(true);
        })
    })
}

/**
 * 獲取單本書籍下章節(jié)列表 調(diào)用章節(jié)列表遍歷進(jìn)行抓取內(nèi)容
 * @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("獲取當(dāng)前書籍: " + series.bookName + " 章節(jié)內(nèi)容失敗，進(jìn)入下一部書籍內(nèi)容抓取!");
        callback(null, null);
        return;
    }
    //判斷當(dāng)前數(shù)據(jù)是否已經(jīng)存在
    const bookItemModel = getModel(key);
    const contentLength = await bookHelper.getCollectionLength(bookItemModel, {});
    if (contentLength === res.length) {
        logger.info("當(dāng)前書籍：" + series.bookName + "數(shù)據(jù)庫已經(jīng)抓取完成，進(jìn)入下一條數(shù)據(jù)任務(wù)");
        callback(null, null);
        return;
    }
    await mapSectionList(res);
    callback(null, null);
}

數(shù)據(jù)抓取完了 怎么保存是個(gè)問題

這里我們通過key 來給數(shù)據(jù)做分類，每次按照key來獲取鏈接，進(jìn)行遍歷，這樣的好處是保存的數(shù)據(jù)是一個(gè)整體，現(xiàn)在思考數(shù)據(jù)保存的問題

1 可以以整體的方式進(jìn)行插入

優(yōu)點(diǎn) : 速度快 數(shù)據(jù)庫操作不浪費(fèi)時(shí)間。

缺點(diǎn) : 有的書籍可能有幾百個(gè)章節(jié) 也就意味著要先保存幾百個(gè)頁面的內(nèi)容再進(jìn)行插入，這樣做同樣很消耗內(nèi)存，有可能造成程序運(yùn)行不穩(wěn)定。

2可以以每一篇文章的形式插入數(shù)據(jù)庫。

優(yōu)點(diǎn) : 頁面抓取即保存的方式 使得數(shù)據(jù)能夠及時(shí)保存，即使后續(xù)出錯(cuò)也不需要重新保存前面的章節(jié)，

缺點(diǎn) : 也很明顯 就是慢 ，仔細(xì)想想如果要爬幾萬個(gè)頁面 做 幾萬次*N 數(shù)據(jù)庫的操作 這里還可以做一個(gè)緩存器一次性保存一定條數(shù) 當(dāng)條數(shù)達(dá)到再做保存這樣也是一個(gè)不錯(cuò)的選擇。

/**
 * 遍歷單條書籍下所有章節(jié) 調(diào)用內(nèi)容抓取方法
 * @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("書籍目錄抓取異步執(zhí)行出錯(cuò)!");
                logger.error(err);
                reject(false);
                return;
            }
            const bookName = list[0].bookName;
            const key = list[0].key;

            // 以整體為單元進(jìn)行保存
            saveAllContentToDB(result, bookName, key, resolve);

            //以每篇文章作為單元進(jìn)行保存
            // logger.info(bookName + "數(shù)據(jù)抓取完成，進(jìn)入下一部書籍抓取函數(shù)...");
            // resolve(true);

        })
    })
}

兩者各有利弊，這里我們都做了嘗試。 準(zhǔn)備了兩個(gè)錯(cuò)誤保存的集合,errContentModel, errorCollectionModel,在插入出錯(cuò)時(shí) 分別保存信息到對(duì)應(yīng)的集合中，二者任選其一即可。增加集合來保存數(shù)據(jù)的原因是 便于一次性查看以及后續(xù)操作， 不用看日志。

（PS ，其實(shí)完全用 errorCollectionModel 這個(gè)集合就可以了 ，errContentModel這個(gè)集合可以完整保存章節(jié)信息）

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

我們將每一條書籍信息的內(nèi)容 放到一個(gè)新的集合中，集合以key來進(jìn)行命名。

寫這個(gè)項(xiàng)目 其實(shí)主要的難點(diǎn)在于程序穩(wěn)定性的控制，容錯(cuò)機(jī)制的設(shè)置，以及錯(cuò)誤的記錄，目前這個(gè)項(xiàng)目基本能夠?qū)崿F(xiàn)直接運(yùn)行 一次性跑通整個(gè)流程。 但是程序設(shè)計(jì)也肯定還存在許多問題 ，歡迎指正和交流。

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

本項(xiàng)目地址 地址 : guwen-spider

對(duì)應(yīng)前端 React + Redux + semantic-ui 地址 : guwen-react

對(duì)應(yīng)Node端 Koa2.2 + mongoose 地址 : guwen-node

項(xiàng)目挺簡單的 ，但是多了一個(gè)學(xué)習(xí)和研究 從前端到服務(wù)端的開發(fā)的環(huán)境。

以上です