支持容错式爬行

我认为需要以下几点: - 可靠的调度队列。#7877 是基础。 - 可靠的重复过滤器。 - 持久的调度元数据。`active.json` 仅在关闭时写入。https://GitHub.com/scrapy/scrapy/pull/8152 - 追踪在下载器中或正在解析中的在线请求,以便在恢复时重新调度它们。 - 追踪在线项目,直到它们所属的每个源都将其刷新。 - 可恢复的源:批次 ID 在恢复时存活,部分写入的文件被截断到最后一个完整记录或继续。也许只限于特定存储。 - 持久的`spider.state`。我认为 SQLite 在大多数情况下是正确的磁盘存储方法。在线请求和项目将作为输入恢复,而不是作为部分进度:在恢复时,它们将再次经过整个中间件和管道链,就像重试一样。因此,这需要具有等效性的项目管道,而这取决于用户。我宁愿记录这一点,而不是尝试在链中进行检查点。由于启用它意味着要排列匹配的调度程序,队列,重复过滤器,源设置和扩展,我还会提供一个插件来配置整个集合,并记录它作为开启的方式。我对以下方面不确定: - 哪些源存储和格式可以被恢复。附加到本地`.jl`文件很容易;单个 JSON 数组,压缩流或多部分上传则更加困难。有些可能只是不受支持。 - 同为文件和图像管道:存储中的一半写入的文件与完整的文件无异。 - 持久性粒度。每个请求的一个 fsync 是安全的,而且可能是不可用的;N 个请求或 T 秒的有限窗口更便宜,但此时保证的数据丢失不会再为零。 - 如何测试此功能。在许多不同的点上杀死真实进程似乎是唯一诚实的方法,而这对于我们来说是一种新的测试。 - HTTP 缓存是否仍然是避免在崩溃后重新下载的更好答案。相关: - #2399 - 在崩溃后恢复 - #4106 - 磁盘队列仅在清洁关闭时写入,而内存队列从来没有 - #845, #3333, #3413, #1346 - 在不干净关闭后,`requests.queue` 可能已损坏或大小不合适 - #5153 - 恢复后覆盖 `%(batch_id)s` 来源文件 - #7730 - 来源批次仅在关闭时完成 - #4749 - 一个公共 API 来