Java 使用Storm crawler对每个域进行不同设置(例如速度)的特定于域的爬网

Java 使用Storm crawler对每个域进行不同设置(例如速度)的特定于域的爬网,java,web-crawler,apache-storm,stormcrawler,Java,Web Crawler,Apache Storm,Stormcrawler,我最近才发现了Storm crawler,根据过去的经验和研究以及与不同爬虫的合作,我发现这个基于Apache Storm的项目非常健壮,适用于许多用例和场景 我已经阅读了一些教程,并用一些基本设置测试了storm crawler。我想在我的项目中使用爬虫程序,但有些事情我不确定爬虫程序是否能够完成,甚至不确定它是否适合这样的用例 我想在许多具有特定速度设置的web域上进行大小递归爬网,并限制获取的URL数量。爬网可以在任何时候以不同的设置单独启动(不同的速度,忽略该域的robots.txt,忽

我最近才发现了Storm crawler,根据过去的经验和研究以及与不同爬虫的合作,我发现这个基于Apache Storm的项目非常健壮,适用于许多用例和场景

我已经阅读了一些教程,并用一些基本设置测试了storm crawler。我想在我的项目中使用爬虫程序,但有些事情我不确定爬虫程序是否能够完成,甚至不确定它是否适合这样的用例

我想在许多具有特定速度设置的web域上进行大小递归爬网,并限制获取的URL数量。爬网可以在任何时候以不同的设置单独启动(不同的速度,忽略该域的robots.txt,忽略外部链接)

问题:

  • 风暴爬虫是否适合这种情况
  • 我可以将限制设置为服务器获取的最大页数吗 爬虫
  • 我可以为不同的用户设置获取页面的数量限制吗 域名
  • 我可以单独监视特定域的爬网进度吗
  • 我可以在不需要将修改后的拓扑上传到storm的情况下动态设置设置吗
  • 是否可以暂停或停止爬网(针对特定域)
  • storm crawler通常作为一个部署的拓扑运行吗
我认为,对于其中一些问题,答案可能是定制或编写自己的螺栓或喷嘴。但我宁愿避免修改抓取器螺栓或爬虫程序的主要逻辑,因为这意味着我正在开发另一个爬虫程序


谢谢。

您有非常有趣的问题。我想你可以在这里发现更多:
代码:官方教程:以及一些回复:

很高兴您喜欢StormCrawler

  • 风暴爬虫是否适合这种情况
可能,但您需要修改/定制一些内容

  • 我可以将限制设置为爬网程序获取的最大页面数吗
当前可以设置种子深度的限制,并且每个种子具有不同的值

没有基于URL数量进行全局筛选的机制,但这是可以做到的。这取决于您用来存储URL状态的内容以及相应的spout和status updater实现。例如,如果您使用Elasticsearch存储URL,您可以让URL筛选器检查索引中的URL数量,并基于此筛选URL(存在或不存在)

  • 我可以为不同域设置抓取页面的数量限制吗
您可以专门化上面提出的解决方案,并根据每个域或主机查询已知的URL数量。这样做不需要对核心元素进行任何修改,只需要一个自定义URL过滤器

  • 我可以单独监视特定域的爬网进度吗
同样,这取决于您使用什么作为后端。例如,使用Elasticsearch,您可以使用Kibana查看每个域的URL

  • 我可以在不需要将修改后的拓扑上传到storm的情况下动态设置设置吗
否。启动辅助任务时读取配置。我知道一些用户编写了一个由DB表支持的自定义配置实现,并让他们的组件从中读取,但这意味着要修改大量代码

  • 是否可以暂停或停止爬网(针对特定域)
不是基于每个域,但是您可以添加一个中间螺栓来检查是否应该处理一个域。如果没有,您可以直接使ack失败。这又取决于存储的状态。例如,您还可以向ES喷口添加自定义过滤器,并在状态索引中添加一个字段。每当特定域的爬网应该停止时,您可以修改与特定域匹配的所有URL的字段值

  • storm crawler通常作为一个部署的拓扑运行吗
是的,经常

  • 我认为,对于其中一些问题,答案可能是定制或编写自己的螺栓或喷嘴。但我宁愿避免修改抓取器螺栓或爬虫程序的主要逻辑,因为这意味着我正在开发另一个爬虫程序
StormCrawler是非常模块化的,所以总是有几种方法来做事情;-)


我非常确信,通过修改小型非核心部件,您可以在拥有单个拓扑的同时获得所需的行为。如果需要代码中更重要的部分(例如每种子机器人设置),那么我们可能希望将其添加到代码中-非常欢迎您的贡献。

非常感谢您快速、非常有用和全面的回答。:-)还有一个问题:您提到elasticsearch是存储url状态的一个示例。我在其他一些帖子中也注意到了它,我想知道它与sql存储或其他状态存储相比如何,因为我一直认为elasticsearch最适合索引文档,而不是频繁更新url状态。再次感谢你,你好,米兰。ES后端可能是SC使用最广泛的后端,因为它具有良好的性能、可扩展性和优异的功能,例如与Kibana一起使用。SQLOne很少被使用,相比之下,它是非常基本的