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

張斌 楊彥松 廖雨寒

睿哲科技股份有限公司

一、背景

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

二、Redis和Pika

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

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

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

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

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

優(yōu)勢：

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

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

劣勢：

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

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

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

優(yōu)勢：

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

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

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

劣勢：

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

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

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

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

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

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

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

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

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

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

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

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

六、結(jié)束語

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

審核編輯：符乾江