抓取数据公式，3个变量算错就白搭

抓取数据公式这东西，真正难的不是公式，是三个变量你压根没量过。式子就一行：总耗时约等于请求总量乘以单请求平均耗时再除以并发数，占用的资源约等于请求总量乘以单请求响应体大小。N、t、C、S 四个符号里，有三个是要你自己去填的变量。填错一个，后面算得再细也是白搭——这话不是吓唬人，我见过太多任务跑到一半卡死，回头一看，全是变量取错了。

抓取数据公式只有三条，复杂的是变量怎么取

很多人一上来就盯着并发数调，好像把线程开大点就快了。先别急。公式里真正决定成败的是请求总量和单请求成本，这两个你没实测，光调并发等于闭着眼睛开车。取变量的顺序我一般这么走：先把请求总量数清楚，再抽几十个请求测平均耗时和平均响应大小，最后才定并发。反过来做，你就会一直在救火。

变量一：请求总量，别只数列表页

新手最容易犯的错，是把列表页的页数当成请求总量。实际上一个列表页背后往往挂着几十个详情页，每个详情页可能还要再调两三个接口，翻页参数、筛选条件、排序方式一组合，数量是往上翻的。还有重试——失败重跑的那部分请求，最容易被忽略，一般按成功量的 1.2 到 1.5 倍来留余量比较稳。去重前后的差距也得算进去：你去重省下的是存储，省不下请求。请求总量这个数，宁可数大一点，别数小了。

变量二：并发和频率，线程数不等于 QPS

我见过最典型的一次翻车，就是有人把线程数当成了 QPS。并发是同时在飞的请求数，频率是每秒实际发出去的请求数，目标站只看后者。你开两百个线程，每个线程慢悠悠地一秒一个，对人家就是两百 QPS；反过来你十个线程跑得飞快，也可能是同样的压力。算错了会怎样？轻则返回 429 让你慢点，重则 IP 直接被关小黑屋，任务全废。分布式抓取的时候更要注意，每台机器的 QPS 是叠加的，别只算单机。

变量三：单请求响应体大小，正文之外都算成本

很多人估存储只算正文那点字，结果附件、图片、接口返回的冗余字段一加，实际体积翻好几倍。gzip 压缩前后也差得远，压缩比不是固定的，跟内容类型关系很大。这一项一旦乘以请求总量，直接决定你要买多大磁盘、多少带宽。存储的算法是：单条平均大小乘以条数，再乘以副本数，再乘以留存周期。留存的副本往往被忘掉——原始页面存一份、解析后的字段存一份、备份再一份，三份下来就不是小数目了。

三个变量错一个，现场是什么样

磁盘写满、内存一路涨到进程被杀、数据库连接池被占光、任务队列越堆越长、目标站开始给你返回限速提示——这些症状看着五花八门，根子上基本都能回到那三个变量。早年我抓一个目录站，只按正文大小估了盘，完全没算附件，跑到半夜盘就满了，监控告警响的时候人还在睡。后来学乖了，先跑一小批，量出真实平均值，再按总量放大。小批试跑这一步，省下来的时间比什么都值。

倒着用：先定期望跑完时间，再倒推带宽和机器

正着算容易漏，我倒建议反着来。你先定期望多久跑完，比如一个晚上；用请求总量除以可用秒数，得到需要的 QPS；再乘以单请求平均响应大小，得到每秒要搬运的数据量；换算成带宽记得乘 8，字节变比特这一步特别容易忘。云主机的带宽标的是 Mbps，别把 MB/s 当 Mbps 看，差着八倍，选小了就是天天堵。磁盘和对象存储的容量也顺手按同一套数推一遍，留出增长余量就行。

几个容易漏的乘数，漏一个就回到白搭

重试倍率、去重前后、边抓边写的连接占用、附件的额外体积、留存副本、目标站的改版频率——这些不是主变量，但都是乘数。还有一个隐形的：写入节奏。很多人习惯抓完再统一入库，觉得干净，实际上任务一大内存就顶不住；边抓边写又会长时间占着数据库连接，得看你的库扛不扛得住。原始响应先进对象存储、解析后的字段再进数据库，这个分层是我目前最顺手的做法，回头补数据也方便。

目标站一改版，公式就得重算

抓取数据公式不是算一次就完事的。目标站加了验证、换了接口、上了 CDN、改了分页规则，单请求耗时和失败率立马就变，公式里那几个系数也得跟着调。我现在习惯每隔一段时间抽一批请求重新测平均值，跟之前的数对一下，差得明显就重算。不然你还在用旧参数跑新站，不出问题才怪。

给个能直接照做的顺序：先数请求总量，把重试和去重都算进去；再抽一批请求，量平均耗时和平均响应大小；最后才定并发和机器规格。三个数写在一张纸上，贴在显示器边上，跑任务之前扫一眼。等哪天目标站改版了，把这张纸撕了重写一遍——别舍不得，旧参数留着只会坑你。