因此，我们已经成功运行了stormcrawler，目前主要索引中包含来自我们各个网站的超过200万个网址的索引。效果很好，但是SC似乎没有重新索引它先前索引的网址，而我正在尝试找出原因。
我尝试搜索有关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泛滥成堆的网址，并且无法通过它们的nextFetchDate爬网所有网址，那么其中的某些内容会掉入裂缝吗？
使用比今天更旧的nextFetchDate来查询状态索引中的文档，我看到200万个URL中有140万个过去具有nextFetchDate。
如果爬网程序可以使用最旧的 nextFetchDate来获取网址并开始在其中进行爬网，那就太好了。
如何重新排列在nextFetchDate上丢失的那些URL？
答案 0 :(得分：0)
默认情况下，ES喷口将获得最早的记录。日志显示的内容并不矛盾：它要求分片5的nextFetchDate低于3月20日的记录。
nextFetchDate实际上应该被认为是“不要在日期D之前爬网”，没有东西掉进裂缝。
用比今天更旧的nextFetchDate来查询状态索引中的文档，我发现200万个URL中有140万个过去具有nextFetchDate。
是的，这很正常。
如果搜寻器可以使用最早的nextFetchDate来获取网址并开始在其中进行爬网，那就太好了。
就是这样
如何重新排列在nextFetchDate上丢失的那些URL？
他们不会错过。他们应该被壶嘴挑选
也许检查喷嘴的数量是否与状态索引上的分片数量匹配。每个spout实例都负责一个分片，如果实例数少于分片，那么这些分片将永远不会被查询。
检查日志中应首先获取的特定URL：喷嘴是否完全将其发送？为此，您可能需要将日志转至DEBUG。