Scrayp-集成scrapy_redis和bloomfilter实现增量

  1. 云栖社区>
  2. 博客>
  3. 正文

Scrayp-集成scrapy_redis和bloomfilter实现增量

中乘风 2018-07-13 15:25:00 浏览838
展开阅读全文

前言

(备注一下,我的开发环境不是Linux就是MacOSX,Windows很多写法不是这样的)

在爬取数据的过程中,有时候需要用到定时、增量爬取。定时这里暂且不说,先说增量爬取。

  • 我想要的增量爬取目前只是简单的,根据url请求来判断是否爬过,如果爬过则不再爬。
  • 复杂一些的增量则是重复爬取,根据指定的几个字段判断是否值有变化,值有变化也算作增量,应当爬取且只更新变化部分(比如天猫商品数据,商品的价格有变化则更新价格,但是url是重复的,也应当爬取)

网上增量爬取的文章很多,包括看过慕课网Scrapy课的笔记,但是它还是不完善,我将在这个基础上进行实际集成。


布隆简介

Bloom Filter是一种空间效率很高的随机数据结构,它利用位数组很简洁地表示一个集合,并能判断一个元素是否属于这个集合。Bloom Filter的这种高效是有一定代价的:在判断一个元素是否属于某个集合时,有可能会把不属于这个集合的元素误认为属于这个集合(false positive)。因此,Bloom Filter不适合那些“零错误”的应用场合。而在能容忍低错误率的应用场合下,Bloom Filter通过极少的错误换取了存储空间的极大节省。

输入图片说明

具体的bloomfilter概念和原理应该查看这篇文章:传送,还有《海量数据处理算法》以及《大规模数据处理利器》

布隆优点

相比于其它的数据结构,布隆过滤器在空间和时间方面都有巨大的优势。布隆过滤器存储空间和插入/查询时间都是常数。另外, Hash 函数相互之间没有关系,方便由硬件并行实现。布隆过滤器不需要存储元素本身,在某些对保密要求非常严格的场合有优势。

布隆过滤器可以表示全集,其它任何数据结构都不能;

k 和 m 相同,使用同一组 Hash 函数的两个布隆过滤器的交并差运算可以使用位操作进行。

布隆缺点

但是布隆过滤器的缺点和优点一样明显。误算率(False Positive)是其中之一。随着存入的元素数量增加,误算率随之增加。但是如果元素数量太少,则使用散列表足矣。

另外,一般情况下不能从布隆过滤器中删除元素. 我们很容易想到把位列阵变成整数数组,每插入一个元素相应的计数器加1, 这样删除元素时将计数器减掉就可以了。然而要保证安全的删除元素并非如此简单。首先我们必须保证删除的元素的确在布隆过滤器里面. 这一点单凭这个过滤器是无法保证的。另外计数器回绕也会造成问题。

总的来说,布隆很适合来处理海量的数据,而且速度优势很强。


redis与bloom

去重”是日常工作中会经常用到的一项技能,在爬虫领域更是常用,并且规模一般都比较大。参考文章《基于Redis的Bloomfilter去重》,作者【九茶】还有另一篇文章可以参考《scrapy_redis去重优化,已有7亿条数据》

去重需要考虑两个点:去重的数据量、去重速度。

为了保持较快的去重速度,一般选择在内存中进行去重。

  • 数据量不大时,可以直接放在内存里面进行去重,例如python可以使用set()进行去重。
  • 当去重数据需要持久化时可以使用redis的set数据结构。
    
  • 当数据量再大一点时,可以用不同的加密算法先将长字符串压缩成 16/32/40 个字符,再使用上面两种方法去重;
    
  • 当数据量达到亿(甚至十亿、百亿)数量级时,内存有限,必须用“位”来去重,才能够满足需求。Bloomfilter就是将去重对象映射到几个内存“位”,通过几个位的 0/1值来判断一个对象是否已经存在。
    
  • 然而Bloomfilter运行在一台机器的内存上,不方便持久化(机器down掉就什么都没啦),也不方便分布式爬虫的统一去重。如果可以在Redis上申请内存进行Bloomfilter,以上两个问题就都能解决了。
    
  1. Bloomfilter算法如何使用位去重,这个百度上有很多解释。简单点说就是有几个seeds,现在申请一段内存空间,一个seed可以和字符串哈希映射到这段内存上的一个位,几个位都为1即表示该字符串已经存在。插入的时候也是,将映射出的几个位都置为1。

  2. 需要提醒一下的是Bloomfilter算法会有漏失概率,即不存在的字符串有一定概率被误判为已经存在。这个概率的大小与seeds的数量、申请的内存大小、去重对象的数量有关。下面有一张表,m表示内存大小(多少个位),n表示去重对象的数量,k表示seed的个数。例如我代码中申请了256M,即1<<31(m=2^31,约21.5亿),seed设置了7个。看k=7那一列,当漏失率为8.56e-05时,m/n值为23。所以n = 21.5/23 = 0.93(亿),表示漏失概率为8.56e-05时,256M内存可满足0.93亿条字符串的去重。同理当漏失率为0.000112时,256M内存可满足0.98亿条字符串的去重。

  3. 基于Redis的Bloomfilter去重,其实就是利用了Redis的String数据结构,但Redis一个String最大只能512M,所以如果去重的数据量大,需要申请多个去重块(代码中blockNum即表示去重块的数量)。

  4. 代码中使用了MD5加密压缩,将字符串压缩到了32个字符(也可用hashlib.sha1()压缩成40个字符)。它有两个作用,一是Bloomfilter对一个很长的字符串哈希映射的时候会出错,经常误判为已存在,压缩后就不再有这个问题;二是压缩后的字符为 0~f 共16中可能,我截取了前两个字符,再根据blockNum将字符串指定到不同的去重块进行去重

总结:基于Redis的Bloomfilter去重,既用上了Bloomfilter的海量去重能力,又用上了Redis的可持久化能力,基于Redis也方便分布式机器的去重。在使用的过程中,要预算好待去重的数据量,则根据上面的表,适当地调整seed的数量和blockNum数量(seed越少肯定去重速度越快,但漏失率越大)。


编写代码

安装依赖

根据github上的资源《BloomFilter_imooc》以及思路来编写bloomfilter的代码。

先前说过,bloom是一种算法,而不是插件也不是软件,它依赖于mmh3,所以需要在虚拟环境中安装mmh3.

然而当我在本机的anaconda虚拟环境内安装时,出现了报错:

g++: error trying to exec 'cc1plus': execvp: 没有那个文件或目录

网上查阅了很多文章,找到一个适合我的:传送,大致原因是电脑上的gcc版本与g++版本不一致引起的。可以打开终端用命令:

gcc -v

g++ -v

来查看两个东西的版本,最终发现用g++的时候报错,于是我安装它:

sudo apt-get install g++

如果是在阿里云服务器,命令改成:

yum install gcc-c++

安装成功后,再次到anaconda虚拟环境中安装mmh3,才成功安装。


编写bloom代码

根据文章《将bloomfilter(布隆过滤器)集成到scrapy-redis中》的指引,作者是将github代码下载到本地目录。

而我为了省事,我在site-package里面写。
在site-package下新建bloofilter_scrapy_redis的package包(带init那种),然后在里面新建文件bloomfilter.py,编写代码:

# -*- coding: utf-8 -*-
# 18-1-21 下午2:22
# RanboSpider

import mmh3
import redis
import math
import time


class PyBloomFilter():
    #内置100个随机种子,种子越多需要的内存就越大,内存小的服务器用30个种子就行了
    SEEDS = [543, 460, 171, 876, 796, 607, 650, 81, 837, 545, 591, 946, 846, 521, 913, 636, 878, 735, 414, 372,
             344, 324, 223, 180, 327, 891, 798, 933, 493, 293, 836, 10, 6, 544, 924, 849, 438, 41, 862, 648, 338,
             465, 562, 693, 979, 52, 763, 103, 387, 374, 349, 94, 384, 680, 574, 480, 307, 580, 71, 535, 300, 53,
             481, 519, 644, 219, 686, 236, 424, 326, 244, 212, 909, 202, 951, 56, 812, 901, 926, 250, 507, 739, 371,
             63, 584, 154, 7, 284, 617, 332, 472, 140, 605, 262, 355, 526, 647, 923, 199, 518]

    #capacity是预先估计要去重的数量
    #error_rate表示错误率
    #conn表示redis的连接客户端
    #key表示在redis中的键的名字前缀
    def __init__(self, capacity=1000000000, error_rate=0.00000001, conn=None, key='BloomFilter'):
        self.m = math.ceil(capacity*math.log2(math.e)*math.log2(1/error_rate))      #需要的总bit位数
        self.k = math.ceil(math.log1p(2)*self.m/capacity)                           #需要最少的hash次数
        self.mem = math.ceil(self.m/8/1024/1024)                                    #需要的多少M内存
        self.blocknum = math.ceil(self.mem/512)                                     #需要多少个512M的内存块,value的第一个字符必须是ascii码,所有最多有256个内存块
        self.seeds = self.SEEDS[0:self.k]
        self.key = key
        self.N = 2**31-1
        self.redis = conn
        # print(self.mem)
        # print(self.k)

    def add(self, value):
        name = self.key + "_" + str(ord(value[0])%self.blocknum)
        hashs = self.get_hashs(value)
        for hash in hashs:
            self.redis.setbit(name, hash, 1)

    def is_exist(self, value):
        name = self.key + "_" + str(ord(value[0])%self.blocknum)
        hashs = self.get_hashs(value)
        exist = True
        for hash in hashs:
            exist = exist & self.redis.getbit(name, hash)
        return exist

    def get_hashs(self, value):
        hashs = list()
        for seed in self.seeds:
            hash = mmh3.hash(value, seed)
            if hash >= 0:
                hashs.append(hash)
            else:
                hashs.append(self.N - hash)
        return hashs


pool = redis.ConnectionPool(host='127.0.0.1', port=6379, db=0)
conn = redis.StrictRedis(connection_pool=pool)

这里的pool和conn都是单独连接的,实际上在分布式爬虫中是比较不友好的,多台机器的配置就会烦人,这里暂且这样,后期我再改。

是否配置密码

至于是否配置密码,如何配置密码,在bloomfilter.py文件中,有一句:

pool = redis.ConnectionPool(host='127.0.0.1', port=6379, db=0)
conn = redis.StrictRedis(connection_pool=pool)

其中redis.StrictRedis方法,跟踪(ctrl+左键点击)进去,可以看到init初始化方法里面有个password=None

def __init__(self, host='localhost', port=6379,
                 db=0, password=None, socket_timeout=None,
                 socket_connect_timeout=None,
                 socket_keepalive=None, socket_keepalive_options=None,
                 connection_pool=None, unix_socket_path=None,
                 encoding='utf-8', encoding_errors='strict',
                 charset=None, errors=None,
                 decode_responses=False, retry_on_timeout=False,
                 ssl=False, ssl_keyfile=None, ssl_certfile=None,
                 ssl_cert_reqs=None, ssl_ca_certs=None,
                 max_connections=None):

这里应该是设置password,也就是将服务器redis的权限密码auth设置进来。

pool = redis.ConnectionPool(host='47.98.110.67', port=6379, db=0, password='quinns')
conn = redis.StrictRedis(connection_pool=pool)

即可完成密码的设置。


集成到scrapy_redis中

上面的布隆过滤器代码写好后,需要集成到scrapy_redis中。完成去重任务的是dupefilter.py文件,就要对它进行改造,路径是site-package/scrapy_redis/目录内:

现将刚才编写的布隆选择器导入此文件

from bloomfilter_scrapy_redis.bloomfilter import conn,PyBloomFilter  # 从源码包导入布隆

然后在init方法中初始化布隆选择器(这里贴上整个init代码):

    def __init__(self, server, key, debug=False):
        """Initialize the duplicates filter.

        Parameters
        ----------
        server : redis.StrictRedis
            The redis server instance.
        key : str
            Redis key Where to store fingerprints.
        debug : bool, optional
            Whether to log filtered requests.

        """
        self.server = server
        self.key = key
        self.debug = debug
        self.logdupes = True

       """ 集成布隆过滤器,通过连接池连接redis """
        self.bf = PyBloomFilter(conn=conn, key=key)

接下来改动request_seen方法,在里面对request进行判断,如果此次request请求在redis中存在,则直接返回,如果不存在则添加到redis的队列里面去,让爬虫去爬:

    def request_seen(self, request):
        """
            ……
        """
       
        fp = self.request_fingerprint(request)

        """
        集成布隆过滤
            判断redis是否存在此指纹,如果存在则直接返回true
            如果不存在添加指纹到redis,同时返回false
        """
        if self.bf.is_exist(fp):
            return True
        else:
            self.bf.add(fp)
            return False

        """ 集成布隆过滤器,将下方2行代码注释 """
        # This returns the number of values added, zero if already exists.
        # added = self.server.sadd(self.key, fp)
        # return added == 0

到这里即完成了scrapy_redis对布隆过滤器的集成。


测试

在爬虫代码中编写:

# -*- coding: utf-8 -*-
import scrapy
from scrapy_redis.spiders import RedisSpider
from scrapy.http import Request
from urllib import parse


class JobboleSpider(RedisSpider):
    name = 'jobbole'
    allowd_domains = ["www.gxnhyd.com"]
    redis_key = 'jobbole:start_urls'

    def parse(self, response):
        """
        将当前列表页的每条标的链接拿到 并传给detail进行深入爬取
        通过已知列表页码数量 进行循环爬取 就不用翻页了
        """
        total = response.css('.item .tl.pl10 a')
        for x in total:
            title = x.css('::text').extract_first("")
            title_url = x.css('::attr(href)').extract_first("")
            yield Request(url=parse.urljoin(response.url, title_url), callback=self.parse_detail)

        for i in range(1, 10):
            next_pages = "http://www.gxnhyd.com/deals/p-%s" % (i)
            yield Request(url=next_pages, callback=self.parse)

    def parse_detail(self, response):
        """
        获取当前详情页的标的信息 包括金额 收益 期限 借款人
            投资人列表 - 投资人用户名/投资人投资金额/投资方式/投资时间等
        :param response:
        :return:
        """
        print(response.url)

通过print对爬取情况做观察

开启爬虫后,由于scrapy_redis的特性,需要给redis里面添加start_urls:

lpush jobbole:start_urls http://www.gxnhyd.com/deals [value ...]

爬虫监听到值之后,立即开始爬取,这一步没问题

但是爬完后它空跑了,不会结束,一直空跑。(事实证明,跑空了也不要紧)


二次测试

在第一次测试通过后,我加大了循环次数for i in range(1, 30),看看是否会出现重复的值,结果报错了。

报错信息与bloom是否重复无关,原因是我之前看到空跑,就主动停止了代码,导致redis报错:

MISCONF Redis is configured to save RDB snapshots, but is currently not able to persist

解决办法在这里《redis异常解决:MISCONF Redis 》,在redis-cli用命令解决这个权限问题:

config set stop-writes-on-bgsave-error no

二次测试后,发现可以正常运行了。然后观察到bloom也生效了,但是还是有空跑的问题


解决空跑(这个办法其实不太好,不推荐)

空跑就是爬虫在爬取完所有的队列有,不会自动停止,而是一直请求请求,然后观察redis-server窗口有memory的提示一直在进行。

解决这个空跑问题参考了一些资料《scrapy-redis所有request爬取完毕,如何解决爬虫空跑问题? 》

输入图片说明

根据scrapy-redis分布式爬虫的原理,多台爬虫主机共享一个爬取队列。当爬取队列中存在request时,爬虫就会取出request进行爬取,如果爬取队列中不存在request时,爬虫就会处于等待状态.

可是,如果所有的request都已经爬取完毕了呢?这件事爬虫程序是不知道的,它无法区分结束和空窗期状态的不同,所以会一直处于上面的那种等待状态,也就是我们说的空跑。

那有没有办法让爬虫区分这种情况,自动结束呢?


  • 从背景介绍来看,基于scrapy-redis分布式爬虫的原理,爬虫结束是一个很模糊的概念,在爬虫爬取过程中,爬取队列是一个不断动态变化的过程,随着request的爬取,又会有新的request进入爬取队列。进进出出。
  • 爬取速度高于填充速度,就会有队列空窗期(爬取队列中,某一段时间会出现没有request的情况),爬取速度低于填充速度,就不会出现空窗期。所以对于爬虫结束这件事来说,只能模糊定义,没有一个精确的标准。

可以通过限定爬虫自动关闭时间来完成这个任务,在settings配置:

# 爬虫运行超过23.5小时,如果爬虫还没有结束,则自动关闭
CLOSESPIDER_TIMEOUT = 84600

特别注意 :如果爬虫在规定时限没有把request全部爬取完毕,此时强行停止的话,爬取队列中就还会存有部分request请求。那么爬虫下次开始爬取时,一定要记得在master端对爬取队列进行清空操作。


想象一下,爬虫已经结束的特征是什么?

那就是爬取队列已空,从爬取队列中无法取到request信息。那着手点应该就在从爬取队列中获取request和调度这个部分。查看scrapy-redis源码,我们发现了两个着手点,调度器site-packages\scrapy_redis\schedluer.py和site-packages\scrapy_redis\spiders.py爬虫。

但是爬虫在爬取过程中,队列随时都可能出现暂时的空窗期。想判断爬取队列为空,一般是设定一个时限,如果在一个时段内,队列一直持续为空,那我们可以基本认定这个爬虫已经结束了。

我选择更改调度器,site-packages\scrapy_redis\schedluer.py所以有了如下的改动:

首先在init里面设定一个初始次数

import datetime

    def __init__(self, server,
              ……
                ……

        """

        """ 为解决空跑问题:设定倒计次数 下方根据次数决定何时关闭爬虫,避免空跑"""
        self.lostGetRequest = 0

        if idle_before_close < 0:
            ……
                ……

完整的init方法代码为:

 def __init__(self, server,
                 persist=False,
                 flush_on_start=False,
                 queue_key=defaults.SCHEDULER_QUEUE_KEY,
                 queue_cls=defaults.SCHEDULER_QUEUE_CLASS,
                 dupefilter_key=defaults.SCHEDULER_DUPEFILTER_KEY,
                 dupefilter_cls=defaults.SCHEDULER_DUPEFILTER_CLASS,
                 idle_before_close=0,
                 serializer=None):
      

        """ 为解决空跑问题:设定倒计次数 下方根据次数决定何时关闭爬虫,避免空跑"""
        self.lostGetRequest = 0

        if idle_before_close < 0:
            raise TypeError("idle_before_close cannot be negative")

        self.server = server
        self.persist = persist
        self.flush_on_start = flush_on_start
        self.queue_key = queue_key
        self.queue_cls = queue_cls
        self.dupefilter_cls = dupefilter_cls
        self.dupefilter_key = dupefilter_key
        self.idle_before_close = idle_before_close
        self.serializer = serializer
        self.stats = None

然后到next_request方法中进行修改:

    def next_request(self):
        block_pop_timeout = self.idle_before_close
        request = self.queue.pop(block_pop_timeout)
        if request and self.stats:
            """ 解决空跑问题,这里判断如果获取到request则重置倒计时lostGetRequest """
            self.lostGetRequest = 0
            self.stats.inc_value('scheduler/dequeued/redis', spider=self.spider)
        if request is None:
            """ 
            scrapy_reids跑完数据后不会自动停止,会产生空跑情况,一直空跑 
                每次调度Schedule时如果队列没有数据  则倒计时+1
                50次空跑大约费时5分钟,根据项目需求设定次数,满足空跑次数则主动停止并填写停止原因
            """
            self.lostGetRequest += 1
            if self.lostGetRequest > 10:
                self.spider.crawler.engine.close_spider(self.spider, 'Queue is empty,So active end')
        return request

这样就可以解决空跑的问题了。(事实证明,高兴得太早)


真正解决空跑(这个也不好,不建议。因为scrapy_redis已处理空跑问题(我也不确定))

真是太年轻,不懂事,我以为按照别人的想法实施,就可以解决空跑的问题了。然后当自己亲自测试的时候,发现并不是那么回事。

scrapy是异步的,而且request队列确实会有空闲状态,如果有空闲状态就会+1,用数字进行累加的话,虽然上编写了重置为0的操作,但貌似是不行的,测试没有那么细致,反正当空闲状态达到N次(关闭条件)的时候,就会自动关闭(request队列还在抽取,也会被关闭),那这就是个bug。

首先

思路是对的,然而用+1的方式出错了。我换了个思路,用时间差来决定是否关闭爬虫。逻辑:

  1. 时间差是不会存在累加的情况,所以不会有刚才的bug
  2. 先初始化一个起始时间
  3. 在每次请求队列的时候刷新起始时间
  4. 在每次队列为空的时候开始计时
  5. 计算时间差,如果队列为空的时间减去起始时间的秒数结果大于设定值,则判定为空跑,关闭爬虫

优点

  1. 通过时间差来判断空跑,解决了刚才的bug;
  2. 可以根据时间来关闭爬虫,而不是次数,这样对于日后爬虫的监控更精准

具体的代码如下:

现在init方法设定起始时间

        为解决空跑问题:设定起始时间 
        下方根据记录空跑时间end_times与起始时间的时间差来决定何时关闭爬虫,避免空跑
        """
        self.strat_times = datetime.datetime.now()

然后到next_request方法进行具体的时间差计算和空跑判断,还有爬虫的关闭操作:

    def next_request(self):
        block_pop_timeout = self.idle_before_close
        request = self.queue.pop(block_pop_timeout)
        if request and self.stats:
          """ 解决空跑问题,这里判断如果获取到request则重置起始时间strat_times """
            self.strat_times = datetime.datetime.now()
            self.stats.inc_value('scheduler/dequeued/redis', spider=self.spider)
        if request is None:
           """ 
            scrapy_reids跑完数据后不会自动停止,会产生空跑情况,一直空跑 
                每次调度Schedule时如果队列没有数据  则计算end_times
                当end_times与start_times的时间差close_times超过N秒,就判定为空跑且进行关闭爬虫的操作
            """
            self.end_times = datetime.datetime.now()
            self.close_times = (self.end_times - self.strat_times).seconds
            print("tihs close_times is : ")
            print(self.close_times)
            if self.close_times > 180:
                self.spider.crawler.engine.close_spider(self.spider, 'Queue is empty,So active end')
        return request

看到下图,跑完数据后会根据时间差关闭爬虫

输入图片说明

这样才是真正的解决了空跑的问题


最后运行,可以正常关闭爬虫了。但是结束的时候还会有报错信息:

builtins.AttributeError: 'NoneType' object has no attribute 'start_requests'

2017-12-14 16:18:56 [twisted] CRITICAL: Unhandled Error
Traceback (most recent call last):
  File "E:\Miniconda\lib\site-packages\scrapy\commands\runspider.py", line 89, in run
    self.crawler_process.start()
  File "E:\Miniconda\lib\site-packages\scrapy\crawler.py", line 285, in start
    reactor.run(installSignalHandlers=False)  # blocking call
  File "E:\Miniconda\lib\site-packages\twisted\internet\base.py", line 1243, in run
    self.mainLoop()
  File "E:\Miniconda\lib\site-packages\twisted\internet\base.py", line 1252, in mainLoop
    self.runUntilCurrent()
--- <exception caught here> ---
  File "E:\Miniconda\lib\site-packages\twisted\internet\base.py", line 878, in runUntilCurrent
    call.func(*call.args, **call.kw)
  File "E:\Miniconda\lib\site-packages\scrapy\utils\reactor.py", line 41, in __call__
    return self._func(*self._a, **self._kw)
  File "E:\Miniconda\lib\site-packages\scrapy\core\engine.py", line 137, in _next_request
    if self.spider_is_idle(spider) and slot.close_if_idle:
  File "E:\Miniconda\lib\site-packages\scrapy\core\engine.py", line 189, in spider_is_idle
    if self.slot.start_requests is not None:
builtins.AttributeError: 'NoneType' object has no attribute 'start_requests'

当通过engine.close_spider(spider, ‘reason’)来关闭spider时,有时会出现几个错误之后才能关闭。可能是因为scrapy会开启多个线程同时抓取,然后其中一个线程关闭了spider,其他线程就找不到spider才会报错。


注意事项

编写代码的schedule.py有个next_request方法有这么一句代码:

        request = self.queue.pop(block_pop_timeout)

打开同目录的queue.py文件

输入图片说明

所以,PriorityQueue和另外两种队列FifoQueue,LifoQueue有所不同,特别需要注意。

如果会使用到timeout这个参数,那么在setting中就只能指定爬取队列为FifoQueue或LifoQueue

# 指定排序爬取地址时使用的队列,
# 默认的 按优先级排序(Scrapy默认),由sorted set实现的一种非FIFO、LIFO方式。
# 'SCHEDULER_QUEUE_CLASS': 'scrapy_redis.queue.SpiderPriorityQueue',
# 可选的 按先进先出排序(FIFO)
'SCHEDULER_QUEUE_CLASS': 'scrapy_redis.queue.SpiderQueue',
# 可选的 按后进先出排序(LIFO)
# SCHEDULER_QUEUE_CLASS = 'scrapy_redis.queue.SpiderStack'

数据入库测试

经过多次 的mysql入库测试,发现bloomfilter是生效的,而且增量开始之前,对于那么重复的数据对比过滤是非常快的(仅用了500条数据测试),正常爬取500条数据大约1分钟多一点。在爬取过500多数据后,bloomfilter的略过只用了几秒钟,很短的时间。

这个还是很强的,我很高兴

网友评论

登录后评论
0/500
评论
中乘风
+ 关注