手把手教你搭建一个基于Java的分布式爬虫系统

在不用爬虫框架的情况下，我经过多方学习，尝试实现了一个分布式爬虫系统，并且可以将数据保存到不同地方，类似 MySQL、HBase 等。

因为此系统基于面向接口的编码思想来开发，所以具有一定的扩展性，有兴趣的朋友直接看一下代码，就能理解其设计思想。

虽然代码目前来说很多地方还是比较紧耦合，但只要花些时间和精力，很多都是可抽取出来并且可配置化的。

因为时间的关系，我只写了京东和苏宁易购两个网站的爬虫，但是完全可以实现不同网站爬虫的随机调度，基于其代码结构，再写国美、天猫等的商品爬取，难度不大，但是估计需要花些时间和精力。

因为在解析网页的数据时，比如我在爬取苏宁易购商品的价格时，价格是异步获取的，并且其 API 是一长串的数字组合，我花了几个小时的时间才发现其规律，当然也承认，我的经验不足。

这个系统的设计，除了基本的数据爬取以外，更关注以下几个方面的问题：

如何实现分布式？ 同一个程序打包后分发到不同的节点运行时，不影响整体的数据爬取。
如何实现 URL 随机循环调度？ 核心是针对不同的顶级域名做随机。
如何定时向 URL 仓库中添加种子 URL？ 达到不让爬虫系统停下来的目的。
如何实现对爬虫节点程序的监控，并能够发邮件报警？
如何实现一个随机 IP 代理库？ 目的跟第 2 点有点类似，都是为了反反爬虫。

下面会针对这个系统来做一个整体的基本介绍，我在代码中都有非常详细的注释，有兴趣的朋友可以参考一下代码，最后我会给出一些我爬虫时的数据分析。

另外需要注意的是，这个爬虫系统是基于 Java 实现的，但是语言本身仍然不是最重要的，有兴趣的朋友可以尝试用 Python 实现。

分布式爬虫系统架构

整体系统架构如下：

从上面的架构可以看出，整个系统主要分为三个部分：

爬虫系统
URL 调度系统
监控报警系统

爬虫系统是用来爬取数据的，因为系统设计为分布式，因此，爬虫程序本身可以运行在不同的服务器节点上。

URL 调度系统核心在于 URL 仓库，所谓的 URL 仓库其实就是用 Redis 保存了需要爬取的URL 列表，并且在我们的 URL 调度器中根据一定的策略来消费其中的 URL。从这个角度考虑，URL 仓库其实也是一个 URL 队列。

监控报警系统主要是对爬虫节点进行监控，虽然并行执行的爬虫节点中的某一个挂掉了对整体数据爬取本身没有影响（只是降低了爬虫的速度），但是我们还是希望能够主动接收到节点挂掉的通知，而不是被动地发现。

下面将针对以上三个方面并结合部分代码片段来对整个系统的设计思路做一些基本的介绍。

爬虫系统

爬虫系统是一个独立运行的进程，我们把我们的爬虫系统打包成 jar 包，然后分发到不同的节点上执行，这样并行爬取数据可以提高爬虫的效率。（说明：ZooKeeper 监控属于监控报警系统，URL 调度器属于 URL 调度系统）

随机IP代理器

加入随机 IP 代理主要是为了反反爬虫，因此如果有一个 IP 代理库，并且可以在构建 http 客户端时随机地使用不同的代理，那么对我们进行反反爬虫会有很大的帮助。

在系统中使用 IP 代理库，需要先在文本文件中添加可用的代理地址信息：

需要注意的是，上面的代理 IP 是我在西刺代理上拿到的一些代理 IP，不一定可用，建议是自己花钱购买一批代理 IP，这样可以节省很多时间和精力去寻找代理 IP。

然后在构建 http 客户端的工具类中，当第一次使用工具类时，会把这些代理 IP 加载进内存中，加载到 Java 的一个 HashMap：

之后，在每次构建 http 客户端时，都会先到 map 中看是否有代理 IP，有则使用，没有则不使用代理：

随机代理对象则通过下面的方法生成：

这样，通过上面的设计，基本就实现了随机 IP 代理器的功能，当然，其中还有很多可以完善的地方。

比如，当使用这个 IP 代理而请求失败时，是否可以把这一情况记录下来；当超过一定次数时，再将其从代理库中删除，同时生成日志供开发人员或运维人员参考，这是完全可以实现的，不过我就不做这一步功能了。

网页下载器

网页下载器就是用来下载网页中的数据，主要基于下面的接口开发：

基于此，在系统中只实现了一个 http get 的下载器，但是也可以完成我们所需要的功能了：

网页解析器

网页解析器就是把下载的网页中我们感兴趣的数据解析出来，并保存到某个对象中，供数据存储器进一步处理以保存到不同的持久化仓库中，其基于下面的接口进行开发：

网页解析器在整个系统的开发中也算是比较重头戏的一个组件，功能不复杂，主要是代码比较多，针对不同的商城不同的商品，对应的解析器可能就不一样了。

因此需要针对特别的商城的商品进行开发，因为很显然，京东用的网页模板跟苏宁易购的肯定不一样，天猫用的跟京东用的也肯定不一样。

所以这个完全是看自己的需要来进行开发了，只是说，在解析器开发的过程当中会发现有部分重复代码，这时就可以把这些代码抽象出来开发一个工具类了。

目前在系统中爬取的是京东和苏宁易购的手机商品数据，因此就写了这两个实现类：

数据存储器

数据存储器主要是将网页解析器解析出来的数据对象保存到不同的表格，而对于本次爬取的手机商品，数据对象是下面一个 Page 对象：

对应的，在 MySQL 中，表数据结构如下：

而在 HBase 中的表结构则为如下：

即在 HBase 中建立了两个列族，分别为 cf1、cf2，其中 cf1 用来保存 id source price comment brand url 字段信息；cf2 用来保存 title params imgUrl 字段信息。

不同的数据存储用的是不同的实现类，但是其都是基于下面同一个接口开发的：

然后基于此开发了 MySQL 的存储实现类、HBase 的存储实现类还有控制台的输出实现类，如 MySQL 的存储实现类，其实就是简单的数据插入语句：

而 HBase 的存储实现类，则是 HBase Java API 的常用插入语句代码：

当然，至于要将数据存储在哪个地方，在初始化爬虫程序时，是可以手动选择的：

目前还没有把代码写成可以同时存储在多个地方，按照目前代码的架构，要实现这一点也比较简单，修改一下相应代码就好了。

实际上，是可以先把数据保存到 MySQL 中，然后通过 Sqoop 导入到 HBase 中，详细操作可以参考我写的 Sqoop 文章。

仍然需要注意的是，如果确定需要将数据保存到 HBase 中，请保证你有可用的集群环境，并且需要将如下配置文档添加到 classpath 下：

对大数据感兴趣的同学可以折腾一下这一点，如果之前没有接触过的，直接使用 MySQL 存储就好了，只需要在初始化爬虫程序时注入 MySQL 存储器即可：

URL调度系统

URL 调度系统是实现整个爬虫系统分布式的桥梁与关键，正是通过 URL 调度系统的使用，才使得整个爬虫系统可以较为高效（Redis 作为存储）随机地获取 URL，并实现整个系统的分布式。

URL仓库

通过架构图可以看出，所谓的 URL 仓库不过是 Redis 仓库，即在我们的系统中使用 Redis 来保存 URL 地址列表。

正是这样，才能保证我们的程序实现分布式，只要保存了 URL 是唯一的，这样不管我们的爬虫程序有多少个，最终保存下来的数据都是只有唯一一份的，而不会重复。

同时 URL 仓库中的 URL 地址在获取时的策略是通过队列的方式来实现的，待会通过 URL 调度器的实现即可知道。

另外，在我们的 URL 仓库中，主要保存了下面的数据：

种子 URL 列表，Redis 的数据类型为 list

种子 URL 是持久化存储的，一定时间后，由 URL 定时器通过种子 URL 获取 URL，并将其注入到我们的爬虫程序需要使用的高优先级 URL 队列中。

这样就可以保证我们的爬虫程序可以源源不断地爬取数据而不需要中止程序的执行。

高优先级 URL 队列，Redis 的数据类型为 set

什么是高优先级 URL 队列？其实它就是用来保存列表 URL 的。那么什么是列表 URL 呢？

说白了就是一个列表中含有多个商品，以京东为例，我们打开一个手机列表：

该地址中包含的不是一个具体商品的 URL，而是包含了多个我们需要爬取的数据（手机商品）的列表。

通过对每个高级 URL 的解析，我们可以获取到非常多的具体商品 URL，而具体的商品URL，就是低优先 URL，其会保存到低优先级 URL 队列中。

那么以这个系统为例，保存的数据类似如下：

低优先级 URL 队列，Redis 的数据类型为 set

低优先级 URL 其实就是具体某个商品的 URL，如下面一个手机商品：

通过下载该 URL 的数据，并对其进行解析，就能够获取到我们想要的数据。

那么以这个系统为例，保存的数据类似如下：

URL调度器

所谓 URL 调度器，就是 URL 仓库 Java 代码的调度策略，不过因为其核心在于调度，所以将其放到 URL 调度器中来进行说明，目前其调度基于以下接口开发：

其基于 Redis 作为 URL 仓库的实现如下：

通过代码分析也可以知道，其核心就在如何调度 URL 仓库（Redis）中的 URL。

URL定时器

一段时间后，高优先级 URL 队列和低优先 URL 队列中的 URL 都会被消费完。

为了让程序可以继续爬取数据，同时减少人为的干预，可以预先在 Redis 中插入种子 URL，之后定时让 URL 定时器从种子 URL 中取出 URL 存放到高优先级 URL 队列中，以此达到程序定时不间断爬取数据的目的。

URL 消费完毕后，是否需要循环不断爬取数据根据个人业务需求而不同，因此这一步不是必需的，只是也提供了这样的操作。

因为事实上，我们需要爬取的数据也是每隔一段时间就会更新的，如果希望我们爬取的数据也跟着定时更新，那么这时定时器就有非常重要的作用了。

不过需要注意的是，一旦决定需要循环重复爬取数据，则在设计存储器实现时需要考虑重复数据的问题，即重复数据应该是更新操作。

目前在我设计的存储器不包括这个功能，有兴趣的朋友可以自己实现，只需要在插入数据前判断数据库中是否存在该数据即可。

另外需要注意的一点是，URL 定时器是一个独立的进程，需要单独启动。

定时器基于 Quartz 实现，下面是其 job 的代码：

调度器的实现如下：

监控报警系统

监控报警系统的加入主要是为了让使用者可以主动发现节点宕机，而不是被动地发现，因为实际中爬虫程序可能是持续不断运行的。

并且我们会在多个节点上部署我们的爬虫程序，因此很有必要对节点进行监控，并且在节点出现问题时可以及时发现并修正，需要注意的是，监控报警系统是一个独立的进程，需要单独启动。

基本原理

首先需要先在 ZooKeeper 中创建一个 /ispider 节点：

监控报警系统的开发主要依赖于 ZooKeeper 实现，监控程序对 ZooKeeper 下面的这个节点目录进行监听：

爬虫程序启动时会在该节点目录下注册一个临时节点目录：

当节点出现宕机时，该临时节点目录就会被 ZooKeeper 删除。

同时因为我们监听了节点目录 /ispider，所以当 ZooKeeper 删除其下的节点目录时（或增加一个节点目录），ZooKeeper 会给我们的监控程序发送通知。

即我们的监控程序会得到回调，这样便可以在回调程序中执行报警的系统动作，从而完成监控报警的功能。

ZooKeeper Java API使用说明

可以使用 ZooKeeper 原生的 Java API，我在另外写的一个 RPC 框架（底层基于 Netty 实现远程通信）中就是使用原生的 API。

不过显然代码会复杂很多，并且本身需要对 ZooKeeper 有更多的学习和了解，这样用起来才会容易一些。

所以为了降低开发的难度，这里使用第三方封装的 API，即 curator，来进行 ZooKeeper 客户端程序的开发。

爬虫系统ZooKeeper注册 

在启动爬虫系统时，我们的程序都会启动一个 ZooKeeper 客户端来向 ZooKeeper 来注册自身的节点信息，主要是 IP 地址。

并在 /ispider 节点目录创建一个以该爬虫程序所在的节点 IP 地址命名的节点，如 /ispider/192.168.43.116，实现的代码如下：

应该注意到的是，我们创建的节点为临时节点，要想实现监控报警功能，必须要为临时节点。

监控程序

首先需要先监听 ZooKeeper 中的一个节点目录，在我们的系统中，设计是监听 /ispider这个节点目录：

在上面注册了 ZooKeeper 中的 watcher，也就是接收通知的回调程序，在该程序中，执行我们报警的逻辑：

当然，判断节点是否挂掉，上面的逻辑还是存在一定的问题的，按照上面的逻辑，假如某一时刻新增节点和删除节点事件同时发生，那么其就不能判断出来，所以如果需要更精准的话，可以将上面的程序代码修改一下。

邮件发送模块

使用模板代码就可以了，不过需要注意的是，在使用时，发件人的信息请使用自己的邮箱。

下面是爬虫节点挂掉时接收到的邮件：

实际上，如果购买了短信服务，那么通过短信 API 也可以向我们的手机发送短信。

实战：爬取京东、苏宁易购全网手机商品数据

因为前面在介绍这个系统的时候也提到了，我只写了京东和苏宁易购的网页解析器，所以接下来也就是爬取其全网的手机商品数据。

环境说明

需要确保 Redis、ZooKeeper 服务可用，另外如果需要使用 HBase 来存储数据，需要确保 Hadoop 集群中的 HBase 可用，并且相关配置文件已经加入到爬虫程序的 classpath 中。

还有一点需要注意的是，URL 定时器和监控报警系统是作为单独的进程来运行的，并且也是可选的。

爬虫结果

进行了两次爬取，分别尝试将数据保存到 MySQL 和 HBase 中，给出如下数据情况。

保存到 MySQL

在可视化工具中查看数据情况：

保存到 HBase

在 HDFS 中查看数据情况：

数据量与实际情况分析

京东：京东手机的列表大概有 160 多页，每个列表有 60 个商品数据，所以总量在 9600 左右，我们的数据基本是符合的。

后面通过日志分析可以知道，一般丢失的数据为连接超时导致的，所以在选取爬虫的环境时，更建议在网络环境好的主机上进行。

同时如果可以有 IP 代理地址库就更好了，另外对于连接超时的情况，可以进一步在我们的程序中加以控制。

一旦出现爬取数据失败的 URL，可以将其加入到重试 URL 队列中，目前这一点功能我是没有做，有兴趣的同学可以试一下。

苏宁易购：再来看看苏宁的数据，其有 100 页左右的手机列表，每页也是 60 个商品数据，所以总量在 6000 左右。

但可以看到，我们的数据却只有 3000 这样的数量级（缺少的依然是频繁爬取造成的连接失败问题），这是为什么呢？

这是因为，打开苏宁的某个列表页面后，其是先加载 30 个商品，当鼠标向下滑动时，才会通过另外的 API 去加载其他的 30 个商品数据，每一个列表页面都是如此，所以，实际上，我们是缺少了一半的商品数据没有爬取。

知道这个原因之后，实现也不难，但是因为时间关系，我就没有做了，有兴趣的朋友折腾一下吧。

通过日志分析爬虫系统的性能

在我们的爬虫系统中，每个关键的地方，如网页下载、数据解析等都是有打 logger 的，所以通过日志，可以大概分析出相关的时间参数。

平均下来，下载一个商品网页数据的时间在 200~500 毫秒不等，当然这个还需要取决于当时的网络情况。

另外，如果想要真正计算爬取一个商品的时间数据，可以通过日志下面的数据来计算：

下载一个商品页面数据的时间
获取价格数据的时间
获取评论数据的时间

在我的主机上（CPU：E5 10核心，内存：32GB，分别开启 1 个虚拟机和 3 个虚拟机），情况如下：

可以看到，当使用 3 个节点时，时间并不会相应地缩小为原来的 1/3，这是因为此时影响爬虫性能的问题主要是网络问题，节点数量多，线程数量大，网络请求也多。

但是带宽一定，并且在没有使用代理的情况，请求频繁，连接失败的情况也会增多，对时间也有一定的影响，如果使用随机代理库，情况将会好很多。

但可以肯定的是，在横向扩展增加爬虫节点之后，确实可以大大缩小我们的爬虫时间，这也是分布式爬虫系统的好处。

爬虫系统中的反反爬虫策略

在整个爬虫系统的设计中，主要使用下面的策略来达到反反爬虫的目的：

使用代理来访问-->IP 代理库，随机 IP 代理。
随机顶级域名url 访问-->url 调度系统。
每个线程每爬取完一条商品数据 sleep 一小段时间再进行爬取。

总结

需要说明的是，本系统是基于 Java 实现的，但个人觉得，语言本身依然不是问题，核心在于对整个系统的设计以及理解上。

写此文章是希望分享这样一种分布式爬虫系统的架构给大家，如果对源代码感兴趣，可以到我的 GitHub 上查看。

原文发布时间为：2018-06-6

本文作者：叶泳豪

本文来自云栖社区合作伙伴“中生代技术”，了解相关信息可以关注“中生代技术”。