为什么只选一种代理，往往会让成本或效率失衡？
很多团队默认要在长效代理和短效代理之间二选一，认为前者更稳定，后者更节省。这个判断忽略了一个关键事实：同一条数据链路中的不同请求，对IP持续时间的要求并不相同。
以网站采集器为例，一次完整任务可能同时包含入口访问、分页遍历、详情获取、状态保持和失败重试。入口与状态保持更依赖出口连续性，普通列表页和详情页则更关注覆盖效率。
如果全部使用长效代理，会出现两个问题：
- 大量一次性请求占用长期资源，单位有效数据成本偏高。
- 某个出口状态下降后，后续请求可能继续沿用，问题持续时间更长。
- 并发扩大时，需要同步增加稳定出口数量，资源弹性不足。
如果全部使用短效代理，也会出现另一组问题：
- 需要连续状态的任务频繁更换出口，重复初始化次数增加。
- 同一任务前后访问环境变化过快，容易触发网站访问频率控制。
- 重试、重新建立连接和重新加载上下文会消耗额外算力与时间。
因此，长效代理和短效代理的组合目标不是追求某种固定比例，而是让每类请求使用足够但不过度的资源。
长效代理和短效代理分别适合承担什么任务？
长效与短效的区别不应只按IP持续时间判断，还要看任务是否依赖连续状态。
| 判断维度 | 更适合长效代理 | 更适合短效代理 |
|---|---|---|
| 任务持续时间 | 单个任务持续较长 | 单次请求或短批次任务 |
| 状态连续性 | 前后请求需要保持一致 | 请求之间相对独立 |
| 地区要求 | 固定地区连续访问 | 多地区快速覆盖 |
| 请求规模 | 中低并发、单任务价值高 | 高并发、大批量请求 |
| 失败代价 | 中途切换会导致整段重做 | 单条失败可快速重试 |
| 调度目标 | 减少切换和重建 | 提高资源利用率 |
| 常见落点 | 状态保持、长轮询、连续分页 | 列表扫描、详情抓取、任务补量 |
这里的长效是相对概念，并不代表出口永久不变。短效也不等于每次请求都必须更换IP。具体持续时间仍要根据目标网站机制、任务周期和服务配置确定。
判断时可以先问一个问题：这个请求更换出口后，需要重新做多少工作？
如果只需重试当前请求，优先进入短效池。如果需要重新建立状态、重新定位进度或重跑一段任务，更适合进入长效池。
怎样把采集链路拆成长效层和短效层？
更容易落地的做法，是把完整链路拆成控制层、任务层和恢复层。
控制层为什么适合使用长效代理？
控制层负责维持任务上下文，包括入口初始化、连续分页、长轮询和需要稳定访问环境的步骤。
这一层的请求量未必最大，但中断后的恢复成本通常较高。使用长效代理的目的，是减少出口变化带来的状态重建，而不是简单追求更长的IP存续时间。
适合放入控制层的任务包括：
- 同一数据源需要连续处理多个分页。
- 单次任务运行时间较长，中途切换会丢失进度。
- 请求之间存在明确的前后依赖。
- 某个地区出口需要在任务周期内保持一致。
任务层为什么更适合使用短效代理？
任务层负责处理可拆分、可并行、可独立重试的数据请求。它通常占据主要请求量，也是控制成本的重点。
适合放入任务层的请求包括：
- 批量详情页获取。
- 多关键词搜索结果采集。
- 多地区公开信息查询。
- 可以按URL或任务编号独立分片的请求。
- 失败后无需重建上下文的补采任务。
恢复层应该承担什么作用？
恢复层不是第三种代理，而是一套切换规则。它决定长效代理异常后能否换出口，也决定短效代理连续失败后是否需要临时保持固定出口。
典型规则可以设置为：
- 短效任务连续失败达到阈值，转入冷却队列，不立即反复请求。
- 长效出口出现持续超时，保存任务进度后再切换。
- 某类页面使用短效代理重试效果较差时，临时升级到长效池验证。
- 恢复成功后，任务重新回到原有资源层，避免长期占用高成本资源。
如何用四步路由规则完成组合配置？
组合策略可以从小流量开始验证，不建议一次性改造全部任务。
第一步：给任务打标签
至少记录以下五类标签：
- 是否依赖连续状态。
- 单次任务预计持续多久。
- 更换出口后的恢复成本。
- 请求并发和数据量。
- 地区是否需要保持一致。
标签不必过度复杂。初期可以只分为高状态依赖、低状态依赖和未知三类。
第二步：建立基础路由
基础路由可以直接写成决策规则：
如果任务依赖连续状态：
分配长效代理
否则如果请求可以独立重试：
分配短效代理
否则：
先进入小流量验证池对于未知任务，可以先抽取5%至10%的流量测试。确认成功率、时延和重试成本后，再逐步扩大到20%或更高，避免路由判断错误影响整条链路。
第三步：设置升级与降级条件
| 当前资源 | 触发条件 | 调整动作 |
|---|---|---|
| 短效代理 | 连续多个统计窗口重试率升高 | 临时升级到长效池 |
| 短效代理 | 单次请求正常但总成本偏高 | 检查轮换是否过于频繁 |
| 长效代理 | 出口状态持续下降 | 保存进度并切换 |
| 长效代理 | 请求之间不存在状态依赖 | 降级到短效池 |
| 长效代理 | 长时间空闲 | 释放资源或缩短占用时间 |
升级不等于永久修改任务类型。问题消失后应重新评估，否则临时策略容易变成长期成本。
第四步：限制单个出口的影响范围
长效出口不应绑定过多任务。更合理的方式是按数据源、地区或任务组分配，使单个出口异常时只影响有限范围。
短效代理也不宜毫无规则地随机切换。可以按任务分片建立短周期粘性，让同一小批次请求在有限时间内保持相近访问环境。
成本账应该怎么算，才不会只看代理采购价？
真正需要关注的是每条成功数据的综合成本，而不是单个IP或单次请求的表面价格。
可使用以下公式：
单位有效数据成本
= 代理资源成本
+ 失败重试成本
+ 计算与带宽成本
+ 状态重建成本
+ 运维处理成本
÷ 成功写入的数据量假设某网站采集器每天处理10万次请求，其中20%依赖连续状态，80%可以独立重试。为便于比较，将各种资源折算为统一成本单位。
| 策略 | 资源占用 | 潜在问题 |
|---|---|---|
| 全部长效 | 10万次请求均占用长效资源 | 一次性请求消耗过多稳定出口 |
| 全部短效 | 10万次请求均频繁轮换 | 2万次状态型请求可能增加重建成本 |
| 分层组合 | 2万次走长效，8万次走短效 | 需要增加路由与监控逻辑 |
这个例子不代表固定的20%与80%配比。它说明成本优化的关键在于：把长效资源留给切换代价高的请求，把短效资源分配给可拆分的大流量任务。
如果某类请求的代理支出下降了10%，但重试量上升30%，最终综合成本可能反而增加。因此，采购成本只能作为输入项，不能单独作为结论。
哪些指标说明当前配比需要调整？
至少需要同时观察效率、质量和成本三组指标。
| 指标组 | 建议指标 | 能回答的问题 |
|---|---|---|
| 效率 | 每分钟成功任务数、P95响应时间、队列等待时间 | 代理策略是否拖慢处理速度 |
| 质量 | 请求成功率、连续分页完成率、重复数据率 | 出口变化是否影响结果完整性 |
| 成本 | 每千条成功数据成本、单任务重试成本 | 表面节省是否转化为真实节省 |
| 稳定 | 状态重建次数、长效出口异常率 | 长效资源是否真正用于高价值任务 |
| 调度 | 升级率、降级率、冷却队列规模 | 路由规则是否过于敏感 |
不要根据一次波动立即调整。更合理的方式是连续观察多个统计窗口，只有当成功率、成本或重试量持续偏离基线时才改变配比。
如果短效任务频繁升级到长效池，说明任务标签可能错误。如果大量长效任务长期没有状态依赖，说明资源分配过度保守。
FAQ
Q：长效代理和短效代理的比例应该设置为多少？
不存在适用于所有业务的固定比例。可以先统计状态型请求占比，将这部分流量分配给长效池，其余进入短效池。上线后再根据成功率、状态重建次数和单位有效数据成本逐步调整。
Q：短效代理是不是切换得越频繁越好？
不是。切换频率应与任务独立性匹配。独立详情请求可以较快轮换，连续分页或同一任务分片则适合保持短周期粘性。过度切换会增加连接开销，也可能降低任务完成率。
Q：长效代理异常后应该立即更换吗？
需要先区分偶发超时和持续异常。偶发问题可以在有限次数内重试，持续异常则应保存任务进度、暂停当前出口并切换。没有检查点就直接更换，可能造成重复处理或数据缺口。
Q：怎样判断某类任务应该从短效升级到长效？
如果该任务持续出现状态重建、连续分页中断或切换后成功率明显下降，可以进入长效验证池。验证有效后再正式调整路由，不应仅凭单次失败永久升级。
Q：组合使用会不会增加系统复杂度？
会增加任务标签、双池调度和监控逻辑，但复杂度可以分阶段控制。初期只实现基础路由和异常切换，等任务量扩大后再加入自动扩缩容、动态阈值和更细的成本核算。
