Mproxy项目实录第1天

前两天一直没时间用电脑，所以有很多时间自己想事。有天想起之前做的岗位信息爬虫老是被封IP，就想要是有个专门提供代理服务器的API就好了。

网上倒是也有这种API啦，但是还是想自己做一个，体验一下从头到尾开发一个API的过程。所以这个博客系列就记录这个项目的整个过程好了。

项目的源码我会同步更新到GitHub，项目地址：https://github.com/mrbcy/Mproxy。

欢迎共同交流。

需求概述

这次我们要做的是一个API，它能够接收客户的请求，返回20条经过验证可用的Http代理服务器地址并实现权限检查、配额管理等功能。

项目的需求是很简单的，那么我们可以分析一下。首先第一步我们肯定需要一套系统来自动的收集、验证代理服务器并把代理服务器的信息写入到数据库。只有这样我们的API才能提供服务。这套系统需要仔细的设计来保证我们提供给客户的代理服务器是基本都可以用的，而不是返回大量不能用的结果。

然后第二步就正式进入我们的API的设计和开发。这边也有很多讲究，比如如何进行权限检查，请求和响应参数及格式的设计，并且需要一套机制保证客户每次请求拿到不同的代理服务器列表。

因为我现在在学习Hadoop等一些框架。所以第三步的话可以利用Hadoop对代理服务器这个主题进行一定的研究。根据爬取和验证代理服务器过程中得到的日志文件，我们可以研究一些问题，比如：

• 哪个省中的代理服务器地址最多
• 哪个运营商的代理服务器地址最多
• 平均来说代理服务器的可用时间是多久
• 几个代理服务器的来源网站提供的代理服务器平均有多少是可用的
• 几个代理服务器的来源网站每天更新多少代理服务器

第四步的话可以在系统中加入Spark等框架，实现上面问题的实时计算。虽然没什么用，但是可以体验一下实时计算的感觉。

如果后面还有时间的话，第五步还可以把这个API改成收费的，提供一个前端界面控制台，然后支持微信、支付宝支付。

收集系统设计

万丈高楼平地起，接下来我们还是从第一步开始，先来实现收集系统。

收集系统需要完成的任务是：从网页中爬取代理服务器列表，并且使用位于不同位置的服务器（比如一个在北京，一个在广州）对收集到的代理服务器进行验证，然后将通过所有地点验证的代理服务器写入数据库。同时系统还需要定时的对数据库中的代理服务器进行重新验证，保证数据库中的代理服务器基本都是可用的。

下面给出一个初步的系统结构图。

整个系统我们需要实现的部分包括爬虫、验证器、收集器和调度器四部分，下面分别阐述一下它们的工作流程，来说明一下上面的系统结构图。

爬虫

爬虫的任务是从网页上提取出代理服务器列表，并把提取出来的代理服务器提交到Kafka上，同时记录日志信息。

爬虫的工作流程如下：

1. 爬虫启动后，从指定的首页开始，爬取详情页地址列表。
2. 对每一个详情页地址，先去MongoDB里面查询一下是否已经爬取过该地址，如果没有爬取过，就把这个地址加入任务列表。
3. 从任务列表中取出一个任务，开始爬取详情页中的代理服务器地址，将提取出的地址信息发送到Kafka集群中，同时记录爬取日志。然后将任务地址保存到MongoDB标注为已爬取状态。

关于使用MongoDB的原因。因为查询是否爬取一个地址是一个高频操作。如果使用MySQL等传统数据库的话，一条条的查询效率会很低而采用批量查询加缓存的方式又会占用很多内存。而MongoDB对查询的优化是非常好的，查询效率非常高，因此选用MongoDB。

关于Kafka中Topic过期时间的选择。有时候不能保证爬取的同时验证器也在工作，所以应该把Kafka中的爬取记录Topic的过期时间选得长一些。初步打算是选择3个月，等以后积累了大量的数据，能得出代理服务器的平均可用时间，然后再进行优化。

验证器

验证器主要负责测试爬虫爬到的代理服务器是否可用，并将可用的代理服务器提交到Kafka集群中，并记录验证日志。

验证器的工作流程如下：

1. 启动后先向ZooKeeper注册自己的信息。
2. 启动后先从ZooKeeper集群中获取调度器发布的工作状态，并添加监听。如果工作状态不存在或指定不工作，那么进行等待。如果指定工作，那么开始进行验证工作。
3. 从Kafka集群中取出一条未验证的代理服务器地址，通过这个代理服务器访问指定网页，然后提取特征判断是否访问成功。
4. 将验证结果提交到Kafka集群。同时记录验证日志。

关于验证器的数量。在项目的设计中，验证器用于确保爬取到的代理服务器可用。因此至少有两个验证器，并且需要分布在不同的地区（图中的华南和华北）。

关于工作状态。上面关于验证器的数量的讨论决定了每个代理服务器必须通过全部验证器的验证才能被收录到数据库中，因此如果有验证器没有启动，其他的验证器是没必要进行工作的。调度器会监听ZooKeeper集群上验证器的状态信息，只有当所有的验证器都在线的时候才会将工作状态设定为工作。

收集器

收集器主要负责把验证器提交到Kafka集群的数据提取出来，并将通过所有验证器验证的代理服务器地址写入到MySQL中。

收集器的工作流程如下：

1. 启动后从配置文件中获得所有的验证器的列表。
2. 从Kafka集群中取得已通过验证器验证的代理服务器地址。
3. 以任务号为单位，将同一任务号的验证结果放在一起。
4. 将任务结果写入MySQL。对于失败的任务，更新其状态信息为“暂时不可用”

关于配置文件中的验证器列表。从配置文件中读取验证器的列表使得收集器可以独立于验证器的工作状态进行工作。即使验证器没有全部启动，还是可以进行收集工作，我认为这是比较好的。

关于任务的超时时间。在收集器收到一个任务的第一条记录时记录一个时间戳。然后后台线程扫描整个任务列表，将超过12小时还没有收到所有验证器验证成功记录的任务判定为失败，清除掉这个记录。

调度器

调度器主要负责对验证器的工作状态进行控制，同时负责定时将需要重新验证的代理服务器地址放入Kafka集群中。定时扫描MySQL中的代理服务器列表，将连续3次未通过定时扫描的代理服务器标记为“永久不可用”，今后不再进行重新扫描。同时负责监听验证器状态，如果有监听器超过24小时不在线，向管理员发送邮件。

调度器的工作流程如下：

1. 启动后获取ZooKeeper中的验证器列表并创建监听。如果所有的验证器都在线，更新验证器工作状态为工作。否则，更新为不工作。
2. 启动扫描线程，定时将上次验证时间超过24小时的代理服务器地址提交到Kafka集群中，等待验证器验证。
3. 启动扫描线程，定时将连续3次未通过重新验证的代理服务器地址状态更新为“永久不可用”。
4. 启动扫描线程，定时将提交到Kafka集群进行重新验证且超过12小时未收到验证结果的代理服务器状态更新为“暂时不可用”。
5. 启动扫描线程，定时读取可用代理服务器数量，小于100条时向管理员发送邮件。
6. 启动扫描线程，定时监控验证器列表，如果连续超过24小时有验证器不在线，向管理员发送邮件。

技术验证

所用的技术，爬虫部分当然是用Python。验证器用Python实现也很方便。数据交互部分准备是用Kafka，也支持Python操作。任务调度部分要用ZooKeeper，也支持Python。数据存储准备使用MySQL，也支持Python。Python上也有强大的日志模块，能够完成日志记录的需求。因此这套系统准备用Python来开发。

因为我对Python不太熟悉，所以还有很多技术需要进一步验证。同时也得找本书学习一下Python的基本语法。

然后今天补了两章Python拿到语法。可以参看：

【书山有路】Python基础教程 第1章

【书山有路】Python基础教程 第2章