把几百个页面塞进一个任务里跑，成功失败都只看到一个总数，出了问题也不知道卡在哪一段。拆开之后，每一步能不能跑、跑多久、用哪条线路，都能单独看。代理IP在这一层的安排，同样依赖这种拆分。
拆到什么粒度
粒度的参照是失败的影响范围。一个单元失败，重跑一次能补回来的量就是合适的粒度。单元太大，一次失败要重跑几百个页面，重跑本身又可能再失败；单元太小，调度记录会膨胀，跑一轮产生的记录比采集本身还占地方。多数情况下，一个单元控制在几十到一两百个页面之间，重跑一次的成本可以接受。
另一个参照是单次运行的时间。单元跑完的时间太短，调度开销占比升高；太长，中途出问题损失的时间又多。让单元在几分钟到半小时之间跑完，节奏比较好掌握。
- 失败影响范围
- 一个单元重跑能补回来的量
- 单次运行时长
- 几分钟到半小时跑完
- 记录开销
- 调度记录不能比采集本身还占地方
这两条参照同时满足，粒度基本就合适了。有时候两者冲突，比如页面本身很慢，那就优先保证重跑成本可控，运行时长的要求放宽一些。
粒度定下来，先跑一轮再说。
拆分之后要维护什么
拆开之后多出一层要做的事：调度记录。哪一批、跑到了哪、用的哪条线路、成功多少失败多少，这些都要能查到。记录不必细到每个页面，但每次调度要对得上。记录太粗，出问题还是查不动；太细则维护成本高。按单元记一轮，通常够用。
粒度偏小会怎样
调度次数变多，记录条目跟着涨，管理的负担上来了。有些场景里单次运行只有几十秒，调度本身的开销反而成了主要成本。遇到这种情况，把相邻的小单元合并回一批，比继续往下拆更省事。合并的时候，代理IP的分配关系要跟着一起改，两张表对不上，就会出现用了旧线路还以为没换过来的情况。
- 单元内页面数控制在几十到一两百
- 单次运行控制在几分钟到半小时
- 调度记录按单元记一轮
- 粒度偏小时优先考虑合并
采集任务用的代理IP，也是按单元来分配的。一个单元用一条线路跑完，出问题只影响这个单元，换线路重跑的范围也清楚。反过来，如果几条线路混在一个单元里随机取用，出了问题说不清是哪条线路的表现，判断依据就丢了。
粒度和线路的对应关系定下来，采集这件事就从「跑完看运气」变成了可核对的过程。哪里慢、哪里失败、哪条线路不适合哪类页面，都能从记录里看出来。单元划清楚，问题才有落点。