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

本文主要是介绍爬虫工作量由小到大的思维转变---＜第二十五章 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, Fieldclass MyItem(Item):data = Field()class MySpider(scrapy.Spider):name = 'my_spider'start_urls = ['http://example.com']def parse(self, response):# 1. 设计一个HTML页面装载一个itemmy_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_1else:# 无效响应或无有效数据：返回一个空列表`[]`，从请求队列中移除对应的request，避免请求堆积yield []# 或者直接把请求给抹掉，释放得干净# return# 重复上述过程，设计第二个HTML页面装载另一个itemmy_item_2 = MyItem()data_2 = response.css('div.data2::text').get()if data_2:my_item_2['data'] = data_2yield my_item_2else: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 ItemAdapterclass DistributePipeline:def process_item(self, item, spider):# 在这里可以根据实际情况将Item分发到不同的存储管道# 这里简单示例将Item直接返回，实际可根据需要分发到多个不同的管道return itemclass DatabaseAPipeline:def __init__(self, database_uri, collection_name):self.database_uri = database_uriself.collection_name = collection_nameself.client = Noneself.db = None@classmethoddef from_crawler(cls, crawler):settings = crawler.settingsdatabase_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 itemclass DatabaseBPipeline:def __init__(self, database_host, database_user, database_password, database_name):self.database_host = database_hostself.database_user = database_userself.database_password = database_passwordself.database_name = database_nameself.connection = Noneself.cursor = None@classmethoddef from_crawler(cls, crawler):settings = crawler.settingsdatabase_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工具检查一下!!

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

这篇关于爬虫工作量由小到大的思维转变---＜第二十五章 Scrapy开始很快,越来越慢(追溯篇)＞的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---