Stormcrawler，状态索引和重新抓取
Stormcrawler, the status index and re-crawling
所以我们成功地拥有了 stormcrawler 运行，主索引目前有超过 200 万 urls 来自我们各个网站的索引。这很好用，但是 SC 似乎没有重新索引它之前索引的 urls，我正在尝试找出原因。
我已经尝试搜索有关 SC 如何从状态索引中选择下一个 url 的详细信息。它似乎没有选择 oldest nextFetchDate，因为我们有状态为 table 且 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 不会查看状态 table 中的任何具有过去日期的 url。那是对的吗？如果 SC 被一大堆 url 淹没并且无法在他们的 nextFetchDate 之前抓取所有这些，是否有一些漏掉了？
查询状态索引中 nextFetchDate 早于今天的文档，我看到 200 万 url 中有 140 万个在过去有 nextFetchDate。
如果爬虫能够获取具有 oldest nextFetchDate 的 url 并从那里开始爬行，那就太好了。
如何重新排队那些 url 在他们的 nextFetchDate 上错过的？
默认情况下，ES spout 将获取最早的记录。日志显示的内容并不矛盾：它要求分片 #5 的 nextFetchDate 低于 3 月 20 日的记录。
nextFetchDate 实际上应该被认为是“不要在日期 D 之前抓取”，没有任何漏洞。
Doing a query for documents in the status index with a nextFetchDate of older than today, I see 1.4 million of the 2 million urls have a nextFetchDate in the past.
是的，这很正常。
It would be nice if the crawler could fetch the url with the oldest nextFetchDate and start crawling there.
这就是它的作用
How to I re-queue up those urls that were missed on their nextFetchDate?
他们没有错过。他们应该被喷子挑出来
也许检查 spout 的数量是否与状态索引中的分片数量相匹配。每个 spout 实例负责一个分片，如果你的实例少于分片，那么这些分片将永远不会被查询。
检查应首先获取的那些特定 URL 的日志：它们是否由 spout 发送？为此，您可能需要将日志转为 DEBUG。
所以我们成功地拥有了 stormcrawler 运行，主索引目前有超过 200 万 urls 来自我们各个网站的索引。这很好用，但是 SC 似乎没有重新索引它之前索引的 urls，我正在尝试找出原因。
我已经尝试搜索有关 SC 如何从状态索引中选择下一个 url 的详细信息。它似乎没有选择 oldest nextFetchDate，因为我们有状态为 table 且 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 不会查看状态 table 中的任何具有过去日期的 url。那是对的吗？如果 SC 被一大堆 url 淹没并且无法在他们的 nextFetchDate 之前抓取所有这些，是否有一些漏掉了？
查询状态索引中 nextFetchDate 早于今天的文档，我看到 200 万 url 中有 140 万个在过去有 nextFetchDate。
如果爬虫能够获取具有 oldest nextFetchDate 的 url 并从那里开始爬行，那就太好了。
如何重新排队那些 url 在他们的 nextFetchDate 上错过的？
默认情况下，ES spout 将获取最早的记录。日志显示的内容并不矛盾：它要求分片 #5 的 nextFetchDate 低于 3 月 20 日的记录。
nextFetchDate 实际上应该被认为是“不要在日期 D 之前抓取”，没有任何漏洞。
Doing a query for documents in the status index with a nextFetchDate of older than today, I see 1.4 million of the 2 million urls have a nextFetchDate in the past.
是的，这很正常。
It would be nice if the crawler could fetch the url with the oldest nextFetchDate and start crawling there.
这就是它的作用
How to I re-queue up those urls that were missed on their nextFetchDate?
他们没有错过。他们应该被喷子挑出来
也许检查 spout 的数量是否与状态索引中的分片数量相匹配。每个 spout 实例负责一个分片，如果你的实例少于分片，那么这些分片将永远不会被查询。
检查应首先获取的那些特定 URL 的日志：它们是否由 spout 发送？为此，您可能需要将日志转为 DEBUG。