一个池服务几类任务：代理IP池的服务边界

一个代理IP池要不要服务所有任务，是个需要提前想清楚的问题。全部混在一起用，看似省事，实际会让指标互相干扰：某类任务的高失败率会污染整体统计，调度规则也很难同时满足两种相反的诉求。这个决定最好在搭池之前就定下来，事后调整的代价要大得多。

分池还是合池

分池的判断依据

判断依据是任务的诉求是否一致。同样追求稳定、同样对速度不敏感的任务，可以合在一个池里；一个要求长会话、一个要求频繁更换，就应当分池。诉求冲突时硬凑在一起，代理IP池的规则会在两者之间反复摇摆，谁都不满意。诉求一致就合，诉求冲突就分，代理IP池的划分标准其实并不复杂。

诉求不同的任务，不适合共用一套调度规则。

分池的代价是资源利用率会下降，因为每个池都要留余量。所以池的数量要控制，按诉求大类分即可，不要按任务逐一分。三到五个池通常就能覆盖多数业务场景，再多管理成本就上来了。把池的数量控制住，代理IP池的维护负担才不会失控。

分池也要有共用机制。

把服务边界定清楚，代理IP池的规则才有稳定的前提。哪类任务走哪个池、哪些资源可以互相调用，写明白之后，扩容与排错都会简单很多。也让后续的容量规划有了单位。

留一条应急通道

边界之外还要留一条应急通道：任一池出问题时，可以从其他池临时借调资源，避免某个业务直接停摆。这条通道平时用不到，需要时却能把停摆时间压到最短。

边界清楚，池才各司其职。