网络推广软件：一次全站扫描被中断后怎样判断已覆盖范围
📱 CCBot/2.0 (https://commoncrawl.org/faq/)
🔗 /9d9d8118c4b4.html
📄
网络推广软件：一次全站扫描被中断后怎样判断已覆盖范围
判断已覆盖范围的关键不是看扫描跑了多久，而是看中断前是否留下了可核对的进度记录。如果没有断点信息，只能通过扫描日志、已处理对象清单和任务时间戳三者交叉比对，圈出一个"确定已覆盖"和"可能未覆盖"的边界区间，再决定是补扫还是重跑。下面用一个假设情境说明这个判断过程。
假设情境：扫描到一半进程被杀掉
假设你用一款网络推广软件对站点做全量扫描，任务跑到中途因为内存不足或手动终止而中断。此时软件界面可能显示"已完成 60%"之类的进度，但这类百分比通常只是按时间或队列长度估算，不能直接当作覆盖依据。你需要先确认三样东西是否留存：扫描日志文件、已写入的结果数据、任务开始与中断的时间戳。三样都缺，就当作完全未覆盖处理，直接重跑并加上断点续扫配置；只要其中两样可用，就可以进入下一步比对。
用日志和结果数据圈出确定边界
扫描日志一般按处理顺序记录每个对象及其状态。找到日志里最后一条"成功处理"的记录，它之前的部分基本可以认为是确定已覆盖的——前提是日志是顺序写入而非并发乱序。如果日志显示多线程并发，最后一条成功记录只能证明该线程覆盖到哪里，其他线程的进度需要分别取各自最后一条记录，取其中的最小值作为确定边界。
结果数据是第二重验证。已写入数据库或导出文件的记录，即使日志丢失也能证明这些对象被处理过。把结果数据里的对象标识去重后排序，与日志的成功记录做交集，交集部分就是最可靠的已覆盖范围。剩下的对象无论日志怎么写，都归入待处理。
区分三种中断原因，决定补扫还是重跑
不同中断原因对应不同的处理方式，判断错了会浪费一轮扫描。
- 进程被系统杀掉：内存或超时导致，已写入的结果通常是完整的，日志可能缺尾部。这种情况下补扫未覆盖部分即可，不必全量重跑。
- 网络请求大面积失败：日志里会出现大量超时或拒绝记录，这类"已处理但失败"的对象不能算覆盖，需要单独列出重试，且要降低并发数，否则会再次失败。
- 任务被手动暂停后未恢复：如果暂停时软件把队列状态持久化了，恢复后能从断点继续；如果没有持久化，队列只在内存里，进程结束后队列丢失，此时只能靠结果数据反推，补扫范围会更大。
一个可操作的动作是：先导出结果数据并统计对象总数，再与站点实际对象总数对比。假设站点有 5000 个页面，结果数据里有 3200 条，那至少还有 1800 个未覆盖；如果日志显示其中 400 条是失败状态，实际需要重试的是 2200 个。这个差值直接决定你下一步是跑增量任务还是全量任务。
补扫前先做一次小范围验证
在正式补扫之前，建议先对"确定已覆盖"边界附近的几十个对象做一次抽样重扫，比对结果是否与首次一致。如果一致，说明中断没有破坏已写入数据的完整性，可以放心只补未覆盖部分；如果出现大量不一致，说明中断时可能有部分写入被截断，此时应放弃增量补扫，改为全量重跑并开启事务写入或临时文件替换机制。
这个验证动作的结果会直接影响后续决策：一致则补扫，不一致则重跑。不要跳过这一步直接补扫，否则可能得到一份看似完整、实际混杂了损坏记录的结果集，后续基于它做的推广调整都会偏。
把覆盖判断固化成可复用的检查点
要减少下次中断后的判断成本，可以在扫描任务里预先设置几个检查点：每处理固定数量的对象就落一次盘，并记录该批次的起止标识。这样即使任务中断，你只需要找到最后一个完整落盘的批次，从它之后开始补扫即可，不需要再做日志与结果的交叉比对。检查点的间隔需要权衡：太密会拖慢扫描速度，太疏则补扫范围大。具体间隔取决于单次扫描的总对象数和可接受的重扫比例，这个比例需要根据你自己的站点规模来定，没有通用数值。
如果使用的网络推广软件本身不支持检查点或断点续扫，那就需要在任务设计阶段把全量扫描拆成多个小批次分别执行，每批完成后单独记录结果。这是用流程弥补工具能力的做法，代价是管理成本上升，但中断后的判断会简单很多。
