扩展至每月十亿次抓取请求一份商业智能案例研究

当一项工作负载逼近每月十亿次请求时，网页抓取的性质就变了。在小规模下，工程问题是如何从网站中提取数据。在企业级规模下，问题转向运维：让刷新流水线按时完成、让成功率保持稳定、消化反爬压力，并确保采集层不会成为下游一切环节的瓶颈。

本案例研究记录了某美国领先的度假租赁情报平台如何把 Crawlbase Enterprise Crawler 集成进既有数据平台，以支撑覆盖 Airbnb、Vrbo、Booking.com 以及区域旅行市场平台的每月约十亿次请求。

该公司的分析平台本就是为接入、归一化和分析大量市场数据而构建的。工程团队没有重新设计这套系统，而是只替换了采集层。Crawlbase 接手了在大规模下可靠获取网页数据的工作，使客户得以继续专注于真正构成产品差异化的部分：把原始市场数据转化为商业智能。

工作负载

该客户的分析平台服务于 220+ 个国家和地区的 2,300 多家专业住宿机构，把公开市场数据与直接预订数据结合起来，为短租行业生成实时市场情报。

与建立在单一数据源上的分析平台不同，他们的系统持续融合两条独立的数据流。第一条来自 65+ 个物业管理系统（PMS）集成，覆盖约 700,000 处托管房源的预订和运营数据。第二条来自对 Airbnb、Vrbo、Booking.com 以及区域度假租赁平台公开市场数据的大规模采集。

每一次抓取都会喂给一项计算：入住率、可订状态、每晚定价、预订提前期、ADR、RevPAR，以及数千个本地市场的竞品基准。在数百万处房源上刷新房源信息、日历、价格和可订状态，正是把日请求量推高到约 33 百万次、把月请求量推向十亿次的原因。

在这个量级上，工程挑战的形态发生了变化。采集一个房源页面很简单。持续采集数百万个页面、在严格的 SLA 窗口内跑完每一轮刷新周期，并且交付速度快到足以让下游分析保持最新，则完全是另一回事。

可靠性开始比峰值吞吐更重要。每一次延迟的抓取、超时或未完成的任务，最终都会表现为过时的市场情报，并反映在数千个专业住宿团队所依赖的入住率趋势、价格基准和预测模型中。

当采集层成为瓶颈

这种量级的工作负载会暴露出小型抓取系统很少出现的问题。

随着日请求量攀升至 33 百万次，采集基础设施开始吃紧。持续高负载下抓取延迟上升，大型刷新任务的完成时间越来越长。请求超时变得更频繁，尤其是在 Airbnb 和 Vrbo 的动态房源页面和可订日历上。单次失败尚可承受；但在数百万次请求中累积起来，就变成了不完整的批次和迟到的刷新周期。

在这个规模上自建并运维代理基础设施本身就是个问题。不同地区的路由性能参差不齐，间歇性网络故障带来不可预测的延迟，而维持代理池的健康状态需要持续投入精力。与此同时，Airbnb 和 Vrbo 不断加强反爬防御，通过封禁、指纹识别和其他检测手段压低了有效抓取产出。

影响远远超出抓取层。每一次延迟的抓取都意味着下游分析在使用更旧的市场数据。可订日历出现偏差，价格快照落后于真实市场状况，而每当刷新窗口超出目标时间，竞品基准就会失去时效性。

最大的成本是工程时间。团队没有把时间用在构建分析能力上，而是把越来越多的工作周花在维护爬虫基础设施、调优代理池、恢复失败任务和排查采集问题上。这些都不是需要修复的缺陷，而是在一个可预测的可靠性比原始吞吐更重要的规模上运行采集层的自然结果。

只替换采集层

分析平台从来不是问题所在。接入、归一化、富化和报表本就能从容处理大量市场数据和预订数据。跟不上节奏的，是负责从公开网络获取这些信息的那一层。

于是团队隔离了瓶颈，只替换了抓取执行环节。Enterprise Crawler 接管了在大规模下可靠获取网页数据所需的一切：

• 请求路由。
• 轮换的数据中心代理和住宅代理基础设施。
• 面向动态页面的 JavaScript 渲染。
• 自动重试与失败恢复。
• 网络韧性。
• 在受支持的市场平台上的反爬处理。

采集之后的一切保持原样。Crawlbase 取回页面后，客户既有的流水线照旧完成校验、归一化、富化和分析，无需任何改动。

把采集与下游处理分离简化了架构。Crawlbase 吸收了请求执行、代理轮换、重试、渲染和反爬韧性的运维复杂度，而客户的基础设施则始终专注于把原始网页数据变成市场情报。

这种拆分也让每一层可以按自己的节奏扩展。随着抓取量增长，采集侧的改进不再需要改动解析、存储或分析。这与我们在大规模网页抓取架构指南中讲到的原则相同，只是应用在了一个生产工作负载上。

迈向每月十亿次请求

检验抓取基础设施最清晰的方式，是看它在工作负载增长时的表现。不少系统在中等流量下表现良好，一旦量级上来就需要动架构手术。

在这六个月里，月度成功请求量从 2025年11月的约 687 百万次增长到 2026年3月的峰值 1.04 十亿次，增幅约 51%。4 月收于 990.7 百万次，仍比窗口起点高出 44%。整个期间的趋势线折合每月约 +52.6 百万次请求。

整个窗口合计 5.52 十亿次成功请求，月均 919 百万次，日均约 30.6 百万次。请注意两个日均数字的区别：约 33 百万次是全量覆盖下跑完一轮完整刷新周期的成本，而 30.6 百万次是六个月真实流量的实测日均值。

这些数字不只是吞吐量。每一次成功的抓取都会喂给解析、富化和分析系统，从而在数百万处受监控房源上产出入住率趋势、价格情报、可订日历、ADR、RevPAR 和竞品基准。这一趋势说明采集层在吸收更多工作负载的同时没有成为限制因素，也没有迫使下游流水线重新设计。

持续负载下的可靠性

扩展请求量只是问题的一半。一个能处理数十亿次请求的平台，只有在工作负载来回波动时结果依然可靠，才真正有用。

在同样的六个月里，尽管月度流量波动明显，成功率却出奇地平稳：

• 平均请求成功率 99.96%。
• 月度成功率介于 99.78% 与 100.00% 之间，区间为 0.22 个百分点。
• 在不断变化的流量模式下，每月接近十亿次成功请求。

成功率直接转化为分析质量。每一次完成的请求都是一份可以校验、解析、富化并纳入入住率模型、价格基准、可订日历和预测仪表盘的市场数据。失败会留下空缺，而空缺同时削弱时效性和完整性。

最有价值的观察是：在吞吐量增长超过 50% 的同时，可靠性几乎没有移动。采集层没有用稳定性去换请求量。对一个持续刷新的分析平台来说，这种一致性往往比更高的峰值更有价值，因为按时跑完每一轮采集周期，才能让下游系统处理新鲜数据，而不是去弥补基础设施带来的噪声。

运维层面的影响

由于每一个下游系统都依赖市场数据按时到达，采集环节的改进会传导到整条流水线。

更可靠的数据流水线

最直接的变化是一致性。抓取任务在 Airbnb、Vrbo、Booking.com 和区域市场平台上都能可预测地完成，因此即便请求量持续攀升，刷新周期仍能在各自的处理窗口内结束。

下游的接入、解析和归一化环节不必再花时间弥补延迟或不完整的批次，而是有更多时间处理新鲜数据。更稳定的刷新意味着更及时的入住率趋势、每晚定价、ADR、RevPAR、可订日历、预订提前期和竞品基准。其结果不只是抓取更快，而是商业智能更可靠。

更低的运维开销

把采集环节交出去，也削减了运行大规模抓取基础设施所需的工程投入。原本用于排查爬虫故障、管理代理和恢复不完整任务的时间，转而用于扩大分析覆盖范围和支持新市场。

随着受监控库存、客户采用率和抓取量的增长，采集层持续支撑着每月约十亿次请求，而没有重新变成一个反复出现的工程问题。

要点

这次部署中的四条原则适用于任何构建大规模网页数据系统的组织。

• 把采集与下游处理分离。 采集、转换、存储和分析具有不同的扩展特性。解耦让每一层可以独立演进，并降低运维复杂度。
• 为可预测的完成而优化，而不是为峰值吞吐。 对持续刷新的平台来说，可靠地跑完每一个周期胜过偶尔的性能高峰。
• 把反爬韧性当作共享基础设施。 在企业级规模上，路由、代理管理、重试和渲染是平台能力，而不是单个抓取器的功能。
• 衡量运维健康度，而不只是请求量。 单看吞吐量说明不了什么。成功率、完成一致性、重试行为和刷新延迟才能显示一条流水线是否真的在交付。

当工作负载增长到数亿甚至数十亿次请求时，成败越来越少取决于单个抓取器，而更多取决于是否把数据采集当作生产基础设施来对待。一个可扩展的采集层，能让工程团队把时间花在创造价值的产品和洞察上，而不是花在底层的爬虫上。

常见问题

每月十亿次抓取请求实际意味着什么？

对这个平台来说，全量覆盖下折合每天约 33 百万次请求，用于刷新 6.15 百万个 Airbnb 房源、1.85 百万个 Vrbo 房源，以及 Booking.com 和区域市场平台上更多库存的房源信息、日历、价格和可订状态。在六个月的实测中，累计达到 5.52 十亿次成功请求，月均 919 百万次。

为什么只替换采集层，而不是整条流水线？

因为流水线的其余部分并不是瓶颈。接入、归一化、富化和报表已经能应对这个量级。隔离抓取执行环节，意味着团队可以在不触碰解析、存储或分析的前提下修复出问题的那一层，之后每一层都能按自己的节奏扩展。

抓取量增加时可靠性会下降吗？

在这里没有。整个期间月请求量增长超过 50%，而成功率始终保持在 99.78% 与 100.00% 之间，区间 0.22 个百分点，平均 99.96%。对持续刷新的分析来说，这种一致性比峰值吞吐更重要，因为错过一个刷新窗口就会表现为过时的市场数据。

在这个规模上如何处理反爬？

作为共享基础设施来处理，而不是写在每个抓取器里的逻辑。请求路由、跨数据中心与住宅代理池的轮换、面向动态页面的 JavaScript 渲染以及自动重试都位于 Enterprise Crawler 内部，因此单个采集任务不必自带绕过代码，也不需要在市场平台每次调整防御时逐一更新。

团队应该衡量哪些指标来判断采集层是否健康？

成功率、完成一致性、重试行为和刷新延迟，而不是单看请求量。吞吐量说明不了刷新周期是否按时完成。真正有用的问题是：每一个周期是否都在自己的窗口内以稳定的成功率完成。

IK

Ian Kalvin

技术支持工程师 · Crawlbase

Crawlbase 技术支持工程师，从生产环境抓取与代理配置中真正出问题的第一线写作。