Stormcrawler，状态索引和重新爬取

Question

所以我们已经成功运行了 Stormcrawler，主索引目前有超过 200 万个来自我们各个网站的网址被编入索引。这很好用，但是 SC 似乎没有重新索引它之前索引的 url，我正在尝试找出原因。

我已尝试搜索有关 SC 如何从状态索引中选择其下一个 url 的详细信息。它似乎没有选择最旧的 nextFetchDate，因为我们在状态表中有文档，nextFetchDate 为 2019 年 2 月 3 日。

查看日志，我看到如下条目：

2019-03-20 09:21:17.221 c.d.s.e.p.AggregationSpout Thread-29-spout-executor[17 17] [INFO] [spout #5]  Populating buffer with nextFetchDate <= 2019-03-20T09:21:17-04:00

这似乎意味着 SC 不会查看状态表中具有过去日期的任何 url。那是对的吗？如果 SC 被大量 url 淹没并且无法在 nextFetchDate 之前抓取所有这些 url，是否有一些会从裂缝中消失？

查询状态索引中 nextFetchDate 早于今天的文档，我发现 200 万个 URL 中有 140 万个具有过去的 nextFetchDate。

如果爬虫可以获取具有 最旧 nextFetchDate 的 url 并开始在那里爬，那就太好了。

如何将那些在 nextFetchDate 上错过的 url 重新排队？

Answer 1

默认情况下，ES spout 将获取最旧的记录。日志显示的内容并不矛盾：它要求为 5 号分片提供 nextFetchDate 低于 3 月 20 日的记录。

nextFetchDate 实际上应该被认为是“在日期 D 之前不要爬行”，没有任何东西会漏掉。

查询状态索引中 nextFetchDate 早于今天的文档，我发现 200 万个 URL 中有 140 万个具有过去的 nextFetchDate。

是的，这很正常。

如果爬虫可以获取具有最旧的 nextFetchDate 的 url 并从那里开始爬取，那就太好了。

这就是它的作用

如何将那些在 nextFetchDate 上错过的 url 重新排队？

他们没有错过。它们应该被喷口采摘

也许检查 spout 的数量是否与您在状态索引上的分片数量相匹配。每个 spout 实例负责一个分片，如果您的实例少于分片，则永远不会查询这些分片。

检查那些应该首先获取的特定 URL 的日志：它们是由 spout 发送的吗？为此，您可能需要将日志转为 DEBUG。