Python实现大规模爬虫的一些套路

我们身边接触最频繁、同时也是最大的爬虫莫过于几大搜索引擎。但是搜索引擎的爬取方式和我们爬虫工程师接触的方式差异比较大，没有太大的参考价值，我们今天要讲的是舆情方向的爬虫（架构以及关键技术原理），主要涉及：

1. 页文本智能提取；
2.分布式爬虫；
3.爬虫 DATA/URL 去重；
4.爬虫部署；
5.分布式爬虫调度；
6.自动化渲染技术；
7.消息队列在爬虫领域的应用；
8.各种各样形式的反爬虫；

一、 页文本智能提取

舆情其实就是舆论情况，要掌握舆情，那么就必须掌握足够多的内容资讯。除了一些开放了商业接口的大型内容/ 交类平台（例如微博）之外，其他都需要依靠爬虫去采集。因此，舆情方向的爬虫工程师需要面对的是千千万万个内容和结构都不同的站点。我们用一个图来表示他们面对的问题：

GNE 的具体算法细节以及源码解析请翻阅《Python3 络爬虫宝典》第 5 章。

有了它，基本上就可以解决 90% 以上的舆情方向爬虫解析的需求，剩下的 10% 可以基于提取规则进行针对性调整或者完全定制化开发，解放了一大波 XPATH 工程师。

二、爬虫 DATA/URL 去重

舆情业务必须紧盯 站是否有新的内容发布，要求是越快越好，但由于各项软硬件限制，通常会要求在 30 分钟内或者 15 分钟内监听到新内容。要实现对目标 站内容变化的监听，那么我们可以选择的比较好的方式就是轮询。不停地访问 页，并且判断是否有“新内容”出现，如果有的话就执行爬取，没有“新内容”就不爬取。最后，如果你的时间不是很紧张，并且又想快速的python提高，最重要的是不怕吃苦，建议你可以架微?信：762459510 ，那个真的很不错，很多人进步都很快，需要你不怕吃苦哦！大家可以去添加上看一下~

那么问题来了，应用程序如何知道哪些内容是“新的”、哪些内容又是“旧的”的呢p>

问题拆解一下，“新内容”就是没有爬过的内容。这时候我们需要用一个东西来记录这篇文章是否被爬取过，每次有要爬取的文章时就比对一下，这就是解决这个问题的办法。

那又依靠什么来进行比对呢p>

我们都知道文章的 URL 几乎都是不变且不会重复的，因此可以选择文章的 URL 作为判定的依据，也就是把爬取过的 URL 放到一个类似列表一样的容器里存储起来，每次有待爬取的 URL 就判断它是否已经被存在容器里，如果在就说明已经爬过了，直接丢弃，进入下一个 URL 的判断流程。整体逻辑就像下面这张图一样：

在只有 1 个爬虫应用的时候，也只有它 1 个读取待爬队列、只有 1 个存储数据、只有它 1 个判断 URL 是否重复。但有几十几百个爬虫应用的时候，就需要区分先后顺序，避免出现多个爬虫应用访问同一个 URL 的情况（因为这不仅浪费时间，还浪费资源）。而且，只有 1 个爬虫应用的时候只需要把它放在 1 台计算机（服务器）上运行就可以了，但是爬虫应用突然变得这么多，又应该如何部署到不同的计算机上呢一个个上传，然后一个个启动吗p>

资源问题

先说资源共享和竞争的情况，为了解决 URL 待爬队列和已经爬队列的共享，那么必须将队列（也就是上面提到的存放 URL 的容器）放到一个可以公开（多个爬虫应用）访问的地方，例如部署在服务器上的 Redis。

这时候又出现一个新状况，随着数据量越来越大，要存储的 URL 越来越多，后面很有可能出现因为存储空间需求过大而导致成本递增的问题。因为 Redis 是利用内存来存储数据的，所以存放的 URL 越多就需要越多的内存，而内存又是硬件设备里价格相对较高的硬件，所以不得不考虑这个问题。最后，如果你的时间不是很紧张，并且又想快速的python提高，最重要的是不怕吃苦，建议你可以架微?信：762459510 ，那个真的很不错，很多人进步都很快，需要你不怕吃苦哦！大家可以去添加上看一下~

好在一个叫做布隆的人发明了一种算法——Bloom Filter（布隆过滤器），这种算法通过哈希映射的方式来标记一个对象（这里是 URL）是否存在，这样可以将内存的占用率大大降低，按 1 亿条长度为 32 字符的 URL MD5 值来计算，使用 Bloom Filter 前后的差距大约在 30倍。关于 Bloom Filter 的算法原理和代码实现解读可翻阅《Python3 络爬虫宝典》第 3 章 。

部署问题

一个个文件上传，一次次手动运行爬虫实在是太累了。你可以向运维同事寻求技术支持，但也可以自己探寻这些能够减轻你工作量的自动化部署方式。目前业内知名的持续集成和部署莫过于 GitLab 的 GitLab Runner 和 GitHub Action，又或者是借助 K8S 的容器化来实现。但它们只能帮助你实现部署和启动，而爬虫应用的一些管理功能就指望不上了。遂，今天要给大家介绍的是另一种实现方式——使用 Crawlab。

Crawlab 是一款由知名外企工程师开发的分布式爬虫管理平台，它不仅支持 Python 语言编写的爬虫，几乎可以兼容大部分编程语言和应用程序。借助 Crawlab，我们可以将爬虫应用分散到不同的计算机（服务器）上，而且能够在可视化界面设定定时任务、查看平台上爬虫应用的状态以及环境依赖等信息。具体如下图所示：

这时候我们就需要用到自动化渲染技术了，实际上像 Chrome 和 FireFox 这样的浏览器都开放了接口，允许其他编程语言按照协议规范操控浏览器。基于这样的技术背景，有团队开发出了像 Selenium 和 Puppeteer 这样的工具，然后我们就可以用 Python （其他语言也可以）代码来操作浏览器了。让浏览器帮助我们做一些用户名密码输入、登录按钮点击、文本和图片渲染、验证码滑动等操作，从而打破 Python 与浏览器本身的差异壁垒，借助浏览器渲染内容后再返回给 Python 程序，然后拿到和我们在 页上看到的一样的内容。

除了浏览器，APP 也有类似的情况。具体操作实践和案例细节可翻阅《Python3 络爬虫宝典》 第 2 章。

五、消息队列在爬虫领域的应用

之前的描述中，我们并没有提到爬取时候的细节。假设这样一个正常的爬虫场景：爬虫先访问 站的文章列表页，然后根据列表页的 URL 进入详情页进行爬取。这里要注意，文章详情页的数量一定是比列表页的数量多 N 倍的，如果列表展示的是 20 条内容，那么就是多 20 倍。最后，如果你的时间不是很紧张，并且又想快速的python提高，最重要的是不怕吃苦，建议你可以架微?信：762459510 ，那个真的很不错，很多人进步都很快，需要你不怕吃苦哦！大家可以去添加上看一下~

如果我们需要爬取的 站很多，那么就会用到分布式爬虫。如果分布式爬虫只是把 1 个爬虫程序复制出 N 份来运行，那么就会出现资源分配不均衡的情况，因为在上面提到的这种情况下，每 1 个爬虫都需要这么干活。实际上我们可以有更好的搭配方式，让它们的资源得到最大利用。例从列表页到详情页可以抽象为生产者和消费者模型：