爬虫工作量由小到大的思维转变---＜第二十五章 Scrapy开始很快,越来越慢(追溯篇)＞

爬虫工作量由小到大的思维转变---＜第二十二章 Scrapy开始很快,越来越慢(诊断篇)＞-CSDN博客

爬虫工作量由小到大的思维转变---＜第二十三章 Scrapy开始很快,越来越慢(医病篇)＞-CSDN博客

前言:

之前提到过,很多scrapy写出来之后,不知不觉就会造成整体scrapy速度越来越慢的情况,且大部分都是内存泄漏问题(前面讲了如何诊断,各人往上看链接); `通药`也就是最普遍,快捷的办法便是调整几个数值(在医病篇里);但是,最根本的原因,还是在scrapy的设计上,出现了大范围堵塞造成的! 那么,现在(诊断)完之后,针对 request和item的堆积问题,进行`根上`的解决以及指正一下scrapy玩家,在设计自己的爬虫时,要规避的一些隐患和高效方法!

正文:

1.requests堆积的问题:

• 1.设计一个HTML页面装载一个item：

  • 在Scrapy中设计爬虫时，最好将爬取的数据存储为Scrapy的Item对象，然后在解析页面时将数据填充到Item中。(备注:最好一个html,装一个尽量不要回传,哪怕用meta装载到回调函数里,尽快将item丢出去!!!!)

• 2.在收到响应后的处理：

  •    - 有效响应： 如果收到有效响应，则立即解析出数据，将数据传递给Item，并将Item传递给管道进行后续处理。(先验证是否有数据,要存数据才实例化item(),否则别创建!!!容易造成item的堆积,增加item的量)
  •    - 无效响应或无有效数据：如果响应为空或者没有有效数据，直接返回一个空列表`[]`。这有助于及时从请求队列中移除对应的request，避免请求堆积。(不返回或者返回None,还会进行后续处理,最直接的就是返回一个[],直接把这个请求给他抹掉;也就是释放得干净!!)

案例:

import scrapy
from scrapy.item import Item, Field

class MyItem(Item):
    data = Field()

class MySpider(scrapy.Spider):
    name = 'my_spider'
    start_urls = ['http://example.com']

    def parse(self, response):
        # 1. 设计一个HTML页面装载一个item
        my_item_1 = MyItem()

        # 假设爬取的第一个数据在HTML页面中的某个CSS选择器下
        data_1 = response.css('div.data1::text').get()

        # 2. 在收到响应后的处理
        if data_1:
            # 有效响应：解析出数据，将数据传递给Item，并将Item传递给管道进行后续处理
            my_item_1['data'] = data_1

            # 先验证是否有数据，要存数据才实例化item()
            yield my_item_1
        else:
            # 无效响应或无有效数据：返回一个空列表`[]`，从请求队列中移除对应的request，避免请求堆积
            yield []

            # 或者直接把请求给抹掉，释放得干净
            # return

        # 重复上述过程，设计第二个HTML页面装载另一个item
        my_item_2 = MyItem()
        data_2 = response.css('div.data2::text').get()

        if data_2:
            my_item_2['data'] = data_2
            yield my_item_2
        else:
            yield []

        # 在这里可以继续处理其他逻辑，或者进行下一步请求
        # ...

创建了两个 MyItem 对象，分别为 my_item_1 和 my_item_2，通过不同的 CSS 选择器提取数据，然后通过 yield 分别返回这两个 MyItem;

---

我们刚刚已经把item进行了分化,他可能已经从最开始的1个item,变成了X个;(这样能解决你的request问题,但是会加大你的item问题)

---

2.item堆积的问题:

在Scrapy中，pipelines是串行处理的。当我们直接将一个包含全部数据的Item传递给pipelines时，整个流程从处理Item数据到存储数据都在为这一个Item服务。为了提高效率，我们可以采用一种巧妙的方式，通过处理多个分化的小Item，从而`间接`实现了并行处理的效果。

为了实现这个思路，我们可以将分化的X个Item，通过(X+1)个pipelines分别进行存储到不同的数据库。这里的(X+1)中的1代表一个专门用于接收Item并快速分发到不同管道的特殊管道。这个设计的目的是减小每个存储管道的负担，降低串行处理的风险，提高整体性能。

举个例子：

1. 假设有一个Item，存了5条数据，将它直接丢给一个管道，整个流程需要0.5秒。

2. 如果有5个Item（也是存了5条数据），分别将它们丢给一个专门的“分管的管道A”，那么这个管道最多只需要花费0.05秒便能处理完一条Item的简单分管任务！对于5个Item，总时间为0.25秒。已知每条数据存入数据库的速度是0.1秒（合并了上面的0.5秒，分析+存储），整个流程的时间就是0.25+0.1=0.35秒完成全部5个Item。

同样的存入5条数据，第二种方式是不是更小而轻便地完成了？而且节省了0.15秒的时间。如果是1000个这样的数据存储，我们就节省了150秒；1W个就是25分钟，10W个就是4个多小时！

案例:

import pymongo
import pymysql
from itemadapter import ItemAdapter

class DistributePipeline:
    def process_item(self, item, spider):
        # 在这里可以根据实际情况将Item分发到不同的存储管道
        # 这里简单示例将Item直接返回，实际可根据需要分发到多个不同的管道
        return item

class DatabaseAPipeline:
    def __init__(self, database_uri, collection_name):
        self.database_uri = database_uri
        self.collection_name = collection_name
        self.client = None
        self.db = None

    @classmethod
    def from_crawler(cls, crawler):
        settings = crawler.settings
        database_uri = settings.get('DATABASE_A_URI')
        collection_name = settings.get('COLLECTION_NAME_A')
        return cls(database_uri, collection_name)

    def open_spider(self, spider):
        self.client = pymongo.MongoClient(self.database_uri)
        self.db = self.client.get_database()

    def close_spider(self, spider):
        self.client.close()

    def process_item(self, item, spider):
        adapter = ItemAdapter(item)
        data_to_store = adapter.asdict()

        # 在这里可以根据实际情况将数据存储到不同的数据库
        self.db[self.collection_name].insert_one(data_to_store)

        return item

class DatabaseBPipeline:
    def __init__(self, database_host, database_user, database_password, database_name):
        self.database_host = database_host
        self.database_user = database_user
        self.database_password = database_password
        self.database_name = database_name
        self.connection = None
        self.cursor = None

    @classmethod
    def from_crawler(cls, crawler):
        settings = crawler.settings
        database_host = settings.get('DATABASE_B_HOST')
        database_user = settings.get('DATABASE_B_USER')
        database_password = settings.get('DATABASE_B_PASSWORD')
        database_name = settings.get('DATABASE_B_NAME')
        return cls(database_host, database_user, database_password, database_name)

    def open_spider(self, spider):
        self.connection = pymysql.connect(
            host=self.database_host,
            user=self.database_user,
            password=self.database_password,
            database=self.database_name,
            charset='utf8mb4',
            cursorclass=pymysql.cursors.DictCursor
        )
        self.cursor = self.connection.cursor()

    def close_spider(self, spider):
        self.connection.close()

    def process_item(self, item, spider):
        adapter = ItemAdapter(item)
        data_to_store = adapter.asdict()

        # 在这里可以根据实际情况将数据存储到不同的数据库表
        sql = "INSERT INTO table_b (field1, field2) VALUES (%s, %s)"
        self.cursor.execute(sql, (data_to_store['field1'], data_to_store['field2']))
        self.connection.commit()

        return item

一个DistributePipeline用于接收Item并快速分发到不同管道，还有两个数据库存储的管道：DatabaseAPipeline和DatabaseBPipeline。根据实际情况调整数据库连接的配置和字段映射!

这种方式的优势在于解决了存储的高并发问题，特别是通过合理使用连接池可以进一步提高数据库操作的效率。

需要注意的是，作为爬虫的主要任务是存储，因此我们可以专注于优化存储的高并发处理(模块化分流)。后续的清洗和分析工作可以通过脚本进行，确保整个爬虫系统高效运行才是王道!!!

总结:

scrapy,就是尽量把每个环节拆开,拆得尽量轻~ 然后,能用并行解决的,坚决不要串行!! 串行绕不过去的,也要想办法把他拆成接近并行!!! 最重要一点,用完就丢(释放!!!!----->关于item释放,我前面文章有Dropitem的说明!)   

最后,你们可以通过今天看到的;对你们的scrapy代码进行重新拆分~ 然后,再用telnet工具检查一下!!

------有收益的,请点赞告诉我!