账号少的时候，一切都看着挺稳，接口也算顺滑。
一旦搞活动、多人同时操作、采集多开几路，问题立刻出现：
- 日常访问突然变慢，登录和下单开始转圈
- 高峰时大量请求排队、超时、返回四二九或五零二
- 面板里节点显示在线正常，业务侧就是各种掉线
大多数情况不是代理质量不行，而是这套出口从来没认真做过容量规划，也没有任何峰值预案。谁抢到线谁先跑，关键请求只能跟着一起被挤掉。
方向可以先记住三条：
- 出口能扛多少要有数字，不靠感觉
- 不同业务要分优先级，关键链路先占资源
- 高峰时谁降级、谁暂停，要提前写死而不是现场决定
这篇只回答一件事：
在出口资源有限时，容量规划和峰值预案怎么搭，才能在高峰下还跑得动。
一、容量问题多半出在三个误区
常见的几个坑，基本都绕不开。
- 只看平均不看峰值
日常统计显示二十 QPS，很安全。实际高峰能冲到五六十，早就超过出口与目标站的承受能力。 - 所有业务挤同一池
运营后台、支付回调、报表查询、爬虫采集统统共用一组出口。爬虫一上量，其他业务的错误率就一起升。 - 没有优先级概念
系统眼里，下单回调和离线报表只是两条任务，高峰时谁抢到资源完全看调度顺序，不看价值。
不改这些，换多少代理、加多少节点，高峰期一样会堵车。
二、先算清这套出口到底能扛多少
容量规划第一步是测，不是猜。
1、测出安全上限
针对某个重点站点，用当前代理池做渐进压测，例如从十 QPS 开始逐级提升到二十、三十、四十，观察三件事：
- 平均响应时长在各档位的变化
- 超时比例何时开始明显抬头
- 四二九、五零二等错误比例何时突然升高
找到那条明显拐点线，然后把安全上限设在拐点下方一些，例如拐点在四十 QPS，可以先把安全上限定在二十五到三十。
2、按业务价值分配容量
有了总上限，再按优先级拆给不同业务，例如在三十 QPS 总额度下：
- 核心链路
登录、支付、订单、关键后台，预留约一半容量，十二到十五 QPS - 重要但非致命业务
报表、轻量查询，分到六到八 QPS - 非实时任务
爬虫、价监、评论抓取，用剩下的七到十 QPS
之后任何新增任务，都必须从某一块额度里挤，而不是悄悄去抢总出口。
三、优先级与限流要绑在一起
只分额度不控节奏，高峰照样会乱。关键是调度时要让“谁先跑”这件事变成规则。
1、按优先级建三个队列
可以在调度层建三类队列。
- 高优队列
登录、下单、支付、售后、关键后台操作 - 中优队列
报表、轻量接口、日常巡检 - 低优队列
爬虫、价监、评论抓取、批量同步
调度次序永远是先高优再中优最后低优。每秒分配额度时：
- 先满足高优额度，高优没吃满，中低优不能抢
- 再给中优剩余额度
- 有余量时才轮到低优，没余量就老实排队
2、三层限流统一生效
限流建议同时做三层。
- 全局层
针对某站点的全部请求总 QPS 不超过容量规划值，例如三十 - 队列层
高优、中优、低优各有自己的 QPS 上限，例如十五、八、七 - 出口层
每条代理 IP 自身也要限速，例如每秒二到三个请求，并发连接上限控制在合理范围
这样，高优链路只要没有自己玩脱，就不会被别的队列挤死。
四、峰值预案要提前写，别出事再想
高峰期最怕的场景是：一切突然变慢，大家才临时讨论“先停谁”。更加可靠的做法，是提前写好几个档位。
1、事先定义降级档位
例如为某站点定义三档运行模式。
- 正常模式
三类队列按原定配额运行 - 业务优先模式
保持高优配额不变
将中优和低优配额整体打折，例如都减半 - 保护模式
只保留登录、支付、核心后台
报表与所有采集暂停或改成极低频率
在代码里把每一档具体数字写死，切档时只切配置，不改流程。
2、触发条件尽量简单
常用的三个信号：
- 一段时间内平均响应时长持续超过平时两到三倍
- 四二九和五零二比例短时间内明显上升
- 代理池内可用节点数量突然减少
任何一个条件满足，就从正常档切到下一档；指标恢复稳定，再往回切。
这样高峰到来时系统会自动让低优任务让路，不需要人一直盯着调度台。
五、配合易路，把容量和预案托在出口层
以上这些逻辑如果完全靠人记，很快就会走样。配合易路代理这种支持线路分组与统计的平台，会轻松很多。
- 可以按业务建不同线路组和标签，例如
核心业务用BIZ_HIGH
报表用BIZ_MID
采集用SPIDER_LOW
代码只绑定标签，不直接写 IP - 易路面板能按线路组看到请求量、成功率和延迟
哪个池被打满、哪个池错误异常，一眼能看出来，方便不断修正容量规划 - 住宅、机房、移动线路都能选
高优业务放在更稳的住宅出口，采集放在机房，既稳又省钱
落地步骤可以很简单：
一、用现有出口在重点站点上做一次压测，拉出各自安全 QPS
二、在易路里按业务价值建线路组和标签，对应好优先队列和配额
三、写好触发条件与档位切换逻辑，让“高峰自动降级”真正跑起来
这样，同一套出口资源在高峰时也能保持有序，关键链路不再反复踩刹车。