鍵值型數(shù)據(jù)庫(kù)在分布式爬蟲系統(tǒng)中的應(yīng)用分析

張斌 楊彥松 廖雨寒

睿哲科技股份有限公司

一、背景

隨著互聯(lián)網(wǎng)的高速發(fā)展，網(wǎng)絡(luò)上的數(shù)據(jù)量呈現(xiàn)爆發(fā)式的增長(zhǎng)。單節(jié)點(diǎn)運(yùn)行的爬蟲系統(tǒng)，在性能等各方面都無(wú)法滿足現(xiàn)有的業(yè)務(wù)需求。因此網(wǎng)絡(luò)爬蟲基于多節(jié)點(diǎn)的分布式協(xié)同運(yùn)行方案成為解決爬蟲性能瓶頸的不二之選。而作為分布式系統(tǒng)的存儲(chǔ)中間件，key－value數(shù)據(jù)庫(kù)（redis和pika）在數(shù)據(jù)結(jié)構(gòu)的支持，高吞吐的性能，接口的易用性等方面都是不錯(cuò)的選擇。

二、Redis和Pika

Redis是一個(gè)開源的使用ANSI C語(yǔ)言編寫、支持網(wǎng)絡(luò)、可基于內(nèi)存亦可持久化的日志型、Key－Value高性能存儲(chǔ)系統(tǒng)。它支持存儲(chǔ)多種類型的value，包括string（字符串）、list（鏈表）、set（集合）、zset（sorted set －－有序集合）和hash（哈希類型）等。這些數(shù)據(jù)類型都支持push／pop、add／remove、取交集、并集、差集及更豐富的操作，而且這些操作都是原子性的。與傳統(tǒng)的內(nèi)存數(shù)據(jù)庫(kù)一樣，為了保證效率，數(shù)據(jù)都是緩存在內(nèi)存中。區(qū)別的是redis會(huì)周期性的把更新的數(shù)據(jù)寫入磁盤或者把修改操作寫入追加的記錄文件，并且在此基礎(chǔ)上實(shí)現(xiàn)了master－slave（主從）同步。

Pika是一個(gè)開源的可持久化的大容量類redis存儲(chǔ)系統(tǒng)。兼容redis的string、hash、list、zset、set等絕大部分的數(shù)據(jù)接口，不用修改代碼即可平滑從redis遷移到pika。主要解決redis由于存儲(chǔ)數(shù)據(jù)量巨大而導(dǎo)致內(nèi)存不足的內(nèi)存容量瓶頸，并且可以像redis一樣，通過(guò)slaveof命令進(jìn)行主從備份，支持全同步和部分同步，pika還可以用在twemproxy或者codis中來(lái)實(shí)現(xiàn)靜態(tài)數(shù)據(jù)分片

本文針對(duì)兩種存儲(chǔ)系統(tǒng)，在分布式爬蟲系統(tǒng)中的應(yīng)用，進(jìn)行對(duì)比，以供參考。

三、兩種數(shù)據(jù)庫(kù)對(duì)比

1）Redis：高性能的key－value存儲(chǔ)解決方案。

優(yōu)勢(shì)：

1．高性能：作為內(nèi)存數(shù)據(jù)庫(kù)，redis擁有超高的吞吐性能；

2．多樣化的數(shù)據(jù)存儲(chǔ)結(jié)構(gòu)：redis支持string（字符串）、list（鏈表）、set（集合）、zset（sorted set －－有序集合）和hash（哈希類型）等；

劣勢(shì)：

1．大數(shù)據(jù)量存儲(chǔ)承載能力有限，存儲(chǔ)成本高；

2．單線程運(yùn)行方式易阻塞，相對(duì)比較脆弱。

2）Pika：利用磁盤存儲(chǔ)來(lái)解決redis的內(nèi)存容量瓶頸。

優(yōu)勢(shì)：

1．使用Redis協(xié)議，兼容redis絕大多數(shù)命令，為兩種數(shù)據(jù)庫(kù)共存提供基礎(chǔ)；

2．使用磁盤存儲(chǔ)，解決redis大數(shù)據(jù)量存儲(chǔ)瓶頸；

3．使用多線程模式，相對(duì)比較健壯。

劣勢(shì)：

1．受磁盤限制，整體性能相對(duì)較差，吞吐量是瓶頸，當(dāng)吞吐量過(guò)高時(shí)會(huì)出現(xiàn)數(shù)據(jù)丟失的情況；

2．缺少成熟的集群多節(jié)點(diǎn)擴(kuò)展方案；

3．不支持分庫(kù)，對(duì)于多業(yè)務(wù)邏輯分類的場(chǎng)景不太友好。

四、分布式爬蟲系統(tǒng)

目前爬蟲系統(tǒng)進(jìn)行頁(yè)面抓取的主要流程：調(diào)度器（Scheduler）接收到request并放入隊(duì)列進(jìn)行排序、去重、轉(zhuǎn)發(fā)等操作，下載器（Downloader）從隊(duì)列獲取到待下載的request，從網(wǎng)絡(luò)獲取到頁(yè)面數(shù)據(jù)后，提供給爬蟲（spider）進(jìn)行分析處理。爬蟲從數(shù)據(jù)中提取新的request給調(diào)度器，同時(shí)將結(jié)構(gòu)化數(shù)據(jù)（item）交給數(shù)據(jù)管道（item pipeline）進(jìn)行存儲(chǔ)分發(fā)等操作。具體流程參考scrapy框架結(jié)構(gòu)圖如下：

要實(shí)現(xiàn)分布式爬蟲，首先需對(duì)調(diào)度器進(jìn)行修改，用網(wǎng)絡(luò)存儲(chǔ)中間件替換本地隊(duì)列，通過(guò)網(wǎng)絡(luò)存儲(chǔ)中間件對(duì)request進(jìn)行多節(jié)點(diǎn)分發(fā)，同時(shí)還需要用中間件存儲(chǔ)request指紋從而實(shí)現(xiàn)去重。

五、鍵值型數(shù)據(jù)庫(kù)在分布式爬蟲系統(tǒng)中的應(yīng)用

要實(shí)現(xiàn)上述功能改造，redis這類的高性能key－value數(shù)據(jù)庫(kù)就目前來(lái)說(shuō)是最佳的適用方案。首先redis的高性能能夠保證大量節(jié)點(diǎn)進(jìn)行request的讀取，同時(shí)redis支持多種數(shù)據(jù)結(jié)構(gòu)及其接口，能夠很方便的實(shí)現(xiàn)各種隊(duì)列的業(yè)務(wù)邏輯。其中可以用list實(shí)現(xiàn)FifoQueue和LifoQueue，用zset實(shí)現(xiàn)PriorityQueue，用set實(shí)現(xiàn)RFPDupeFilter。同時(shí)還可以使用list或者pub／sub來(lái)實(shí)現(xiàn)多任務(wù)調(diào)度和分發(fā)，不需要再另外引入kafka、MQ這類的消息隊(duì)列來(lái)做多任務(wù)管理，從而減小整個(gè)爬蟲系統(tǒng)的架構(gòu)體積；雖然redis能充分滿足整個(gè)爬蟲系統(tǒng)的分布式需求，可是在某些場(chǎng)景下，redis會(huì)出現(xiàn)瓶頸；其中存儲(chǔ)容量則是最主要的瓶頸。

在爬取過(guò)程中，一個(gè)request序列化之后大約占用1KB左右的存儲(chǔ)空間，1GB內(nèi)存則只能處理大約100萬(wàn)個(gè)request。因?yàn)樵L問(wèn)控制之類的原因，爬取一個(gè)擁有千萬(wàn)級(jí)頁(yè)面的網(wǎng)站，redis就需要大約10GB左右的內(nèi)存。一臺(tái)64G內(nèi)存的服務(wù)器也僅僅只能支持5－7個(gè)大型爬取任務(wù)的同時(shí)執(zhí)行。

因此引入pika這種以磁盤為主要存儲(chǔ)的類redis數(shù)據(jù)庫(kù)。pika在保留了redis多樣化數(shù)據(jù)結(jié)構(gòu)的同時(shí)，極大的擴(kuò)展了數(shù)據(jù)存儲(chǔ)容量，從而解決request的容量瓶頸。

可是pika的無(wú)集群模式，同樣對(duì)pika的性能產(chǎn)生很大的制約。在不使用SSD硬盤的情況下，只是單獨(dú)使用pika會(huì)出現(xiàn)大量的慢查詢，導(dǎo)致部分?jǐn)?shù)據(jù)丟失的情況。因?yàn)闆](méi)有集群模式來(lái)實(shí)現(xiàn)多實(shí)例負(fù)載均衡，所以pika的性能擴(kuò)展成本將比redis高不少。

最終在多任務(wù)分布式爬蟲系統(tǒng)中，需要用redis和pika兩種中間件來(lái)支持整個(gè)爬蟲系統(tǒng)的運(yùn)行。其中redis負(fù)責(zé)request指紋和任務(wù)調(diào)度之類高吞吐量的業(yè)務(wù)，pika則負(fù)責(zé)request分發(fā)這種需要高存儲(chǔ)容量的業(yè)務(wù)。

六、結(jié)束語(yǔ)

以上對(duì)Redis和Pika兩種key－value存儲(chǔ)方案在分布式爬蟲系統(tǒng)中的應(yīng)用做了描述，這兩種方案在實(shí)際生產(chǎn)環(huán)境中相輔相成，互相配合，才能支撐起一個(gè)功能健壯，性能強(qiáng)大的成熟的多任務(wù)分布式爬蟲系統(tǒng)。

審核編輯：符乾江