成千上万个站点，日数据过亿的大规模爬虫是怎么实现的？
简介：分布式爬虫、智能解析、消息队列、去重和调度等技术点
我们周围最常遇到和最大的爬虫是主要的搜索引擎。但搜索引擎的爬行方式和我们爬虫工程师使用的方法相差较大，没有太大的参考价值。今天我们要讲的是舆论方向的爬虫（架构和关键技术原理），主要涉及：
智能提取网页文本；
分布式爬虫；
爬虫数据/URL去重；
爬虫部署；
分布式爬虫调度；
自动渲染技术；
消息队列在爬虫领域的应用；
各种形式的反爬虫；
请大家买瓜子，搬好凳子，坐下来学习，准备好争夺文末给出的奖品吧！
1. 网页文本智能提取
舆论实际上就是舆论的状态。把握舆论，就必须掌握足够的内容信息。除了一些大型内容/社交平台开放了商业接口（如微博）外，其他都需要依靠爬虫来采集。因此，舆情爬虫工程师需要面对数千个内容和结构各异的网站。我们用一张图来表示他们面临的问题：
没错，他们的收集器必须能够适应数千个网站的结构，并从不同样式的 HTML 文本中提取主要内容 - 标题、正文、发布时间和作者。
如果是你，你会采用什么样的设计来满足业务需求？
之前我也想象过这样的问题，也看到有朋友在技术群里问类似的问题，但很难得到满意的答案。有人说：
利用分类的方法，将相似的内容归为一组，然后针对一类内容配置提取规则；
使用正则规则提取指定标签中的内容；
利用深度学习和NLP对有意义的内容进行语义分析并提取；
用计算机视觉让人点击，然后根据页面相似度进行分类提取（实际上是分类方法的自动化版本）；
使用算法计算文本的密度，然后提取；
总之，各种想法纷纷涌现，但最终却没有听到实际应用的消息。目前大多数公司采用手动配置XPATH规则的方法。采集时，通过URL匹配相应的提取规则，然后调用规则，实现多站抓取。这种方法非常有效，在企业中已经使用了很长时间，也比较稳定，但是缺点也很明显——费时、费力、费钱！
偶然的一天，看到微信技术群里有人（优秀工程师庆楠）发布了一个自动文本提取的算法库（以下简称GNE）。本库参考了武汉邮电学院洪红辉、丁世涛、黄敖、郭志远等人撰写的论文——《基于文本和符号密度的网页文本提取方法》，并基于纸。 ，即 GNE。其原理是根据文本中标点符号的密度，提取网页DOM中的文本以及其中的标点符号，并利用算法从一个句子扩展到一段文本和一篇文章。
GNE可以有效剔除正文以外的广告、推荐栏、介绍栏等“噪音”内容，准确识别网页正文，识别率高达99%（筛选出的内容）测试内容均来自国内主流门户/媒体平台的文章）。
GNE的具体算法细节和源码分析请阅读《网络爬虫指南》第五章。
有了它，基本可以解决舆情方向爬虫分析90%以上的需求，剩下的10%可以根据抽取规则进行针对性调整或完全定制化开发，解放大量XPATH工程师。
2. 爬虫DATA/URL去重
舆论界一定要关注网站是否有新内容发布。越快越好，但由于各种软硬件限制，通常要求在30分钟或15分钟内监控新内容。要监控目标网站内容的变化，我们可以选择的更好的方式是轮询。不断访问网页，判断是否有“新内容”。如果是这样，请抓取它。如果没有“新内容”，就不要抓取它。
那么问题是，应用程序如何知道哪些内容是“新”、哪些内容是“旧”？
分解问题，“新内容”是之前没有被抓取过的内容。这时候我们就需要用一些东西来记录这篇文章是否被爬取了。每次有文章要爬取的时候，就比较一下。这就是解决这个问题的方法。
那么我们可以依靠什么来进行比较呢？
我们都知道一篇文章的URL几乎总是不变的，不会重复，所以可以选择文章的URL作为判断的依据，即将爬取的URL放入一个类似于列表和存储的容器中它每次都会判断要爬取的URL是否已经存储在容器中。如果是，则说明已爬取，直接丢弃，进入下一个URL的判断过程。整体逻辑如下图所示：
这就是爬虫领域的“去重”。事实上，重复数据删除大致可以分为内容（DATA）重复数据删除和链接（URL）重复数据删除。这里我们只是从舆论的方向来谈一下去重的必要性。如果是电商方向的去重，那么就不能用URL作为判断了。依据，因为电商爬虫（比如比价软件）的目的主要是判断价格变化。这时判断变化的依据应该是产品的关键信息（如价格、折扣），即DATA去重。
既然我们了解了重复数据删除的原理，那么我们应该用什么作为容器来存储重复数据删除的基础呢？ MySQL？雷迪斯？ ？记忆？事实上，大多数工程师选择Redis作为容器来存储重复数据删除的基础，但实际上MySQL和内存都可以作为容器。至于为什么选择Redis，它比其他数据存储有什么优势？您可以阅读《网络爬虫指南》的第3章。
3.分布式爬虫
无论是舆论爬虫还是电商爬虫，其要承担的爬行量都非常大。其范围从每天数百万数据到每天数十亿数据。过去大家所熟知的单机爬虫无论是性能还是资源都无法满足需求。既然1个不够，那就10个、100个吧！这就是分布式爬虫出现的背景。
众所周知，分布式系统和单机系统面临的问题是有区别的。除了相同的业务目标之外，分布式系统还需要考虑多个个体之间的协作，尤其是资源的共享和竞争。
当只有一个爬虫应用时，只有其中一个读取待爬队列，只有一个存储数据，只有一个判断URL是否重复。但当爬虫应用有几十个、上百个时，就需要区分顺序，避免多个爬虫应用访问同一个URL（因为这不仅浪费时间，而且浪费资源）。而且，当只有一个爬虫应用时，只需要在一台计算机（服务器）上运行即可。但如果突然出现这么多爬虫应用，应该如何将它们部署在不同的计算机上呢？手动一张一张上传然后一张一张启动？
资源问题
先说资源共享和竞争。为了解决待爬取的URL队列和已爬取的队列共享的问题，队列（即上面提到的存储URL的容器）必须放置在公众可以访问的地方（多个爬虫应用程序）。的地方，比如部署在服务器上的Redis。
这时，新的情况出现了。随着数据量越来越大，需要存储的URL也越来越多。很可能由于过多的存储空间需求而导致成本增加。由于Redis使用内存来存储数据，因此存储的URL越多，需要的内存就越多。而且内存是一个比较昂贵的硬件设备，所以这个问题不得不考虑。
幸运的是，一个叫Bloom的人发明了一种算法——Bloom（布隆过滤器）。该算法使用哈希图来标记一个对象（这里是一个URL）是否存在，这样可以减少内存的使用。率大大降低。根据1亿个长度为32个字符的URL的MD5值计算，使用Bloom前后相差约30倍。 Bloom算法原理解读和代码实现请阅读《网络爬虫宝典》第三章。
部署问题
一个一个上传文件，一次又一次手动运行爬虫，确实很累。您可以向运营同事寻求技术支持，但您也可以自己探索这些自动化部署方法，以减少您的工作量。目前业界最知名的持续集成和部署是阿里云和，或者是借助K8S容器化来实现。但它们只能帮助你实现部署和启动，爬虫应用的一些管理功能不能指望。那么，今天我要给大家介绍的是另一种实现方法——使用。
是由国外知名公司工程师开发的分布式爬虫管理平台。它不仅支持各种语言编写的爬虫，而且几乎兼容大多数编程语言和应用程序。借此，我们可以将爬虫应用分发到不同的计算机（服务器）上，在可视化界面上设置定时任务，查看平台上爬虫应用的状态、环境依赖等信息。详细信息如下图所示：
面对如此实用的平台工具，作为工程师的我们不禁产生疑问：
它如何跨计算机传播文件？
它是如何实现不同计算机（多个节点）之间的通信的？
它是如何实现多语言兼容的呢？
……
其中，我们比较关心的多节点通信是借助Redis来实现的，去中心化的文件同步是借助Redis来实现的。更多详情请阅读《网络爬虫指南》第六章。
除了此类平台之外，爬虫工程师还经常接触框架以及相关的衍生库。团队官方开发了一个名为 的库，专门用于部署框架开发的爬虫应用。在部署应用程序时，我们通常只需要执行一行命令就可以将爬虫程序部署到服务器上。你想知道背后的逻辑吗：
程序以什么形式上传到服务器？
程序如何在服务器上运行？
为什么可以查看每个任务的开始时间和结束时间？
中途取消任务执行的功能是如何实现的？
它的版本控制是如何实现的？
如果应用程序不是用框架编写的，是否可以实现像上面几点那样的监控和操作呢？
实际上，应用程序会被打包成后缀为“.egg”的压缩包，并以HTTP的形式上传到服务器。当服务器程序需要执行这个程序时，它首先将其复制到操作系统的临时文件夹中，执行时将其导入到当前环境中，执行完毕后删除该文件。至于它的执行时间和中断操作，它实际上使用的是进程接口。详细内容请阅读《网络爬虫指南》第六章。
4、自动渲染技术
为了达到炫酷的效果，或者为了节省静态资源占用的带宽，很多网站都用它来优化页面内容。程序本身无法解释HTML代码，因此无法获取我们在浏览器中“看到”的内容，但实际上并不是“真实”的，因为这些内容是浏览器渲染出来的，只存在于浏览器中， HTML 文档和文件中的代码仍然存在。图片、视频和特效不会出现在代码中。我们看到的一切都是浏览器的结果。
由于无法获取浏览器渲染的内容，当我们照常编写代码爬取上述数据时，会发现获取到的数据与看到的不一样，任务失败。
这时候我们就需要用到自动化渲染技术。事实上，浏览器喜欢并且已经开放了接口，允许其他编程语言按照协议规范来控制浏览器。基于这样的技术背景，一些团队开发了诸如 和 之类的工具，然后我们就可以使用代码（也可以是其他语言的）来操作浏览器。让浏览器帮我们做一些操作如用户名密码输入、登录按钮点击、文字图片渲染、验证码滑动等，从而打破与浏览器本身差异的障碍，用浏览器来渲染内容然后将其返回给程序，然后得到与我们在网络上看到的相同的内容。
除了浏览器之外，APP也有类似的情况。具体操作实践和案例详情请参考《网络爬虫指南》第二章。
5、消息队列在爬虫领域的应用
在前面的描述中，我们没有提及爬取的细节。假设这样一个正常的爬虫场景：爬虫首先访问网站的文章列表页面，然后根据列表页面的URL进入详情页面进行爬虫。这里需要注意的是，文章详情页数必须是列表页数的N倍。如果列表显示20条内容，那么就多了20倍。
如果我们需要爬取很多网站，我们就会使用分布式爬虫。如果分布式爬虫只复制N个爬虫程序来运行，那么就会出现资源分配不均的情况，因为在上面提到的情况下，每个爬虫都需要做这项工作。其实我们可以有更好的匹配方法，最大限度地利用自己的资源。比如从列表页到详情页，可以抽象为生产者和消费者模型：
4号和5号爬虫应用只负责从列表页中提取详情页的URL，然后推送到队列中。其他几个爬虫程序从队列中取出详情页的URL进行爬行。当列表页和详情页数量差距比较大时，我们可以增加右侧的爬虫数量。当间隙较小时，减少右侧履带的数量（或增加左侧履带的数量，视情况而定）。
左边的爬虫程序相对于队列的“数据采集生产线”来说是生产者，右边的爬虫程序则是消费者。有了这样的结构，我们就可以根据实际情况调整生产者或消费者的熟练程度，以最大限度地利用资源。另一个好处是，当生产者获得的 URL 越来越多，但消费者暂时无法消费时，URL 会一直存储在队列中，当消费能力增加时可以再次实现平衡。有了这样的生产线，我们就不用担心突然大量的URL涌入或者突然消耗掉队列中的所有URL。队列削峰填谷的能力不仅在后端应用中大放异彩，在爬虫中也同样大放异彩。应用程序也发挥着重要作用。
爬虫（及分布式爬虫）程序访问消息队列的具体实现和细节请阅读《网络爬虫集锦》第四章。
6.各种形式的反爬虫
你想要，但我不会给你！
网站不会轻易允许您抓取网站上的内容。它们常常在网络协议、浏览器特性、编程语言差异、人机差异等方面给爬虫工程师设置障碍，常见的有滑块验证码、拼图验证码等。 、屏蔽IP、检查、要求登录、设置复杂的加密逻辑、混淆前端代码等。
水来了，大地覆盖你，兵来了，你挡住！爬虫工程师和目标网站工程师之间的来回，就像士兵之间的勾心斗角一样扣人心弦。 《反爬原理与绕过实战》一书涵盖了市面上80%以上的反爬方法和爬虫技巧，并详细讲解了双方使用的战术，让观众学到很多技巧从它。具体细节你可以阅读本书，领略科技世界！
概括
今天我们一起学习了日数据量过亿的大规模爬虫实践之路上的关键技术点，包括智能文本提取、分布式爬虫、爬虫部署与调度、去重、自动化渲染等。一旦学会这些技术掌握了，实现一个日处理过亿数据的爬虫不成问题。
这些经验均来自于一线爬虫工程师。同时，这些技术和设计都经过了长期工作的验证，可以直接应用到工作中。