Java多线程爬虫及分布式爬虫架构

　　在我们调试爬虫程序的时候，单线程爬虫没什么问题，但是当我们在线上环境使用单线程爬虫程序去采集网页时，单线程就暴露出了两个致命的问题：

　　采集效率特别慢，单线程之间都是串行的，下一个执行动作需要等上一个执行完才能执行

　　对服务器的CUP等利用率不高，想想我们的服务器都是 8核16G，32G 的只跑一个线程会不会太浪费啦

　　线上环境不可能像我们本地测试一样，不在乎采集效率，只要能正确提取结果就行。在这个时间就是金钱的年代，不可能给你时间去慢慢的采集，所以单线程爬虫程序是行不通的，我们需要将单线程改成多线程的模式，来提升采集效率和提高计算机利用率。

　　多线程的爬虫程序设计比单线程就要复杂很多，但是与其他业务在高并发下要保证数据安全又不同，多线程爬虫在数据安全上到要求不是那么的高，因为每个页面都可以被看作是一个独立体。要做好多线程爬虫就必须做好两点：第一点就是统一的待采集 URL 维护，第二点就是 URL 的去重， 下面我们简单的来聊一聊这两点。

　　维护待采集的 URL

　　多线程爬虫程序就不能像单线程那样，每个线程独自维护这自己的待采集 URL，如果这样的话，那么每个线程采集的网页将是一样的，你这就不是多线程采集啦，你这是将一个页面采集的多次。基于这个原因我们就需要将待采集的 URL 统一维护，每个线程从统一 URL 维护处领取采集 URL ，完成采集任务，如果在页面上发现新的 URL 链接则添加到 统一 URL 维护的容器中。下面是几种适合用作统一 URL 维护的容器：

　　JDK 的安全队列，例如 LinkedBlockingQueue

　　高性能的 NoSQL，比如 Redis、Mongodb

　　MQ 消息中间件

　　URL 的去重

　　URL 的去重也是多线程采集的关键一步，因为如果不去重的话，那么我们将采集到大量重复的 URL，这样并没有提升我们的采集效率，比如一个分页的新闻列表，我们在采集第一页的时候可以得到 2、3、4、5 页的链接，在采集第二页的时候又会得到 1、3、4、5 页的链接，待采集的 URL 队列中将存在大量的列表页链接，这样就会重复采集甚至进入到一个死循环当中，所以就需要 URL 去重。URL 去重的方法就非常多啦，下面是几种常用的 URL 去重方式：

　　将 URL 保存到数据库进行去重，比如 redis、MongoDB

　　将 URL 放到哈希表中去重，例如 hashset

　　将 URL 经过 MD5 之后保存到哈希表中去重，相比于上面一种，能够节约空间

　　使用 布隆过滤器(Bloom Filter)去重，这种方式能够节约大量的空间，就是不那么准确。

　　关于多线程爬虫的两个核心知识点我们都知道啦，下面我画了一个简单的多线程爬虫架构图，如下图所示：

　　分布式爬虫架构

　　分布式爬虫架构是一个大型采集程序才需要使用的架构，一般情况下使用单机多线程就可以解决业务需求，反正我是没有分布式爬虫项目的经验，所以这一块我也没什么可以讲的，但是我们作为技术人员，我们需要对技术保存热度，虽然不用，但是了解了解也无妨，我查阅了不少资料得出了如下结论：

　　分布式爬虫架构跟我们多线程爬虫架构在思路上来说是一样的，我们只需要在多线程的基础上稍加改进就可以变成一个简单的分布式爬虫架构。因为分布式爬虫架构中爬虫程序部署在不同的机器上，所以我们待采集的 URL 和 采集过的 URL 就不能存放在爬虫程序机器的内存中啦，我们需要将它统一在某台机器上维护啦，比如存放在 Redis 或者 MongoDB 中，每台机器都从这上面获取采集链接，而不是从 LinkedBlockingQueue 这样的内存队列中取链接啦，这样一个简单的分布式爬虫架构就出现了，当然这里面还会有很多细节问题，因为我没有分布式架构的经验

       以上就是动力节点Java培训机构小编介绍的“Java多线程爬虫及分布式爬虫架构”的内容，希望对大家有帮助，如有疑问，请在线咨询，有专业老师随时为你服务。

　　相关内容

　　java多线程的状态转换以及基本操作

　　常见Java多线程面试题总结

　　Java多线程学习,深入解析