题目重点：面向搜索索引，支持周期重抓，暂不渲染JavaScript。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 百亿页面、周期重抓、下游搜索索引、不做JS渲染是题目场景。24小时全量重抓是额外容量追问。
- robots、host限速与站点错误重试遵守配置策略；实时公开规则如需落实现行规范应另查官方文档。
解题路线
- frontier由URL状态表、优先候选队列、host可用时间堆构成。先按优先级选可抓URL，再由host串行/并发上限与nextAllowedTime约束实际发出。不能只用全局高优先队列压垮单站。
- URL规范化有风险：删除query参数可能改变内容。精确URL哈希作为身份，Bloom只作预筛或低价值候选过滤，重要URL必须精确确认避免误判漏抓。内容checksum处理精确重复，近似签名只产生候选。
- 按host分片，worker持租约与fencing token；持久化frontier与抓取状态。失败重试保留attempt/nextTry，解析出的新URL先落库再发布，不让worker崩溃漏掉闭环。
- 重抓由新鲜度/变化率/重要性预算调度；限制host总量、URL模式与深度来处理日历陷阱。重定向和跨域发现重新经过身份与host调度，不能绕过限速。
手动走一遍
100亿/86400≈11.57万页/秒；假设平均100KB原始载荷，约11.6GB/s，约92.6Gbps不含重试、TLS和副本。DNS缓存只是一个瓶颈，并不能证明足够。同host有100万高优先URL但允许1请求/秒，24小时最多抓86400条；全量24小时目标可能与礼貌合同不可同时满足，要报告容量矛盾。
规模与取舍
存储/传输成本按页面数×平均大小；scheduler候选操作通常O(logH)或分片队列成本，H是活跃host数。观测抓取覆盖、新鲜度、host违规、重复率和恢复漏抓。
易错点与追问
容易失分的边界
- 用Bloom误判为已访问会漏抓，不可称准确去重。
- 一致性hash仅分配host，不自动防止两个持旧租约worker同时抓取。
继续深挖
- robots策略缓存失效与抓取中变化如何处理？
- 重要页面的优先级、礼貌等待与24小时目标冲突时如何给产品可量化选择？
