我想制作一个具有成本效益的分布式抓取工具（即我可以为其添加额外的服务器以更快地处理网址），专注于将整个单个网站作为服务进行抓取。它会抓取目标网站的每个网址以及下载例如该网站在其他网站上直接引用的任何图像或文件（但不能抓取除此之外的其他网站）。由于目标网站所有者会授予对其网站进行抓取的权限，因此抓取工具可能不太礼貌，例如每秒下载20页。
这种架构听起来合理吗？
AWS ECS2实例，可以根据需要杀死或联机。
运行PostgreSQL的AWS RDS数据库，用于存储页面元数据。
网址边界（要抓取的网址），看到的网址列表，网址抓取深度等都会存储在数据库中。
工作人员会轮询数据库以查找新工作，以及哪个工作人员正在处理存储在数据库中的内容。
我维护一个URL数据库表，以查看哪些工作人员会在启动和完成对该URL的爬网时标记时间戳。如果工人死亡，另一名工人将注意到工作在超时期限内没有完成工作。
如果一个工作人员每秒可以爬几百页，那么工人一次抓取大量的URL以提高效率是有意义的。我不确定一种简单的方法来限制每秒对单个主机进行的爬网次数。
当工作人员将链接排队时，执行此操作的数据库查询将避免将已经看到的链接排入队列。
我已经阅读了一些关于你不应该（并且应该！）将PostgreSQL用作队列的文章...我在这里使用数据库作为队列的想法是它的更具成本效益（AWS SQS听起来每百万个请求的成本为0.50美元），工作人员无论如何都需要将页面元数据写入数据库，因此它需要能够处理已经存在的吞吐量（可能MQ系统可以做到这一点）它让我编写复杂的排队逻辑。
以上听起来有效吗？我已经阅读了一些有关抓取工具的文章，但大多数人都没有明确说明工作人员如何沟通以及存储URL边界的位置，以便它能够适应故障。
答案 0 :(得分：0)
关于您的边界，我认为您应该从frontera
查看distributed-frontera或scrapinghubFrontera为您的前沿链接提供了很多预先存储和评分。此外，它是用Python编写的，可以很容易地推理和编辑。
最后一点 - 文档很精彩，让我在推理网络抓取工具如何扩展方面有了先机。
使用frontera与scrapyd和自定义仪表板一直是一个真正的享受。目前部署在Digital Ocean上，但我们可以使用frontera-distributed和EMR（HBASE）轻松部署到EC2和AWS。
您的提案似乎应该有效。