失败的表现有哪几种？
多线程采集频繁失败时，第一步不是加IP，而是分类失败表现。不同的失败类型指向完全不同的根因，盲目加量只能解决其中一种。
| 失败表现 | 典型症状 | 最可能的根因 |
|---|---|---|
| 大面积超时 | 多数线程同时卡住，响应时间从毫秒级飙到10秒以上 | 代理服务连接池饱和或目标站限速 |
| 间歇性429/503 | 部分线程返回限流状态码，其余正常 | 单IP请求密度过高，触发目标站频率控制 |
| 成功率随时间下降 | 刚启动时成功率95%+，跑半小时后降到70%以下 | IP被目标站标记，未及时轮换 |
| 返回内容异常 | HTTP 200但页面内容是验证码页或空白 | IP已被目标站识别为异常来源 |
| 连接直接被拒 | 线程刚发起请求就收到connection refused | 代理服务端限流或IP资源耗尽 |
关键判断：如果失败集中在"间歇性429/503"和"成功率随时间下降"这两类，大概率不是IP总量问题，而是单IP的使用方式有问题。 只有"连接直接被拒"且代理服务端日志明确提示配额耗尽，才指向真正的IP数量不足。
怎么判断IP数量是否真的不足？
IP数量是否够用，不能拿"线程数 vs IP数"做简单除法。需要算一个关键指标：单IP请求密度。
单IP请求密度公式：
单IP请求密度 = 总线程数 × 每线程每分钟请求数 ÷ 同时可用IP数这个值代表"每个IP每分钟需要承担多少次请求"。密度越高，单IP被目标站频率控制机制识别的概率越大。
密度阈值参考：
| 单IP请求密度 | 风险等级 | 说明 |
|---|---|---|
| < 3次/分钟 | 低风险 | 多数目标站不会触发频率控制 |
| 3-10次/分钟 | 中风险 | 部分有频率控制的站点可能触发限速 |
| 10-30次/分钟 | 高风险 | 大多数站点会触发限速或验证 |
| > 30次/分钟 | 极高风险 | 几乎必定触发限制，成功率会断崖式下跌 |
实际计算示例：
以舆情监测场景为例，假设配置如下：
| 参数 | 值 |
|---|---|
| 并发线程数 | 200 |
| 每线程每分钟请求数 | 6次 |
| 同时可用IP数 | 500个 |
| 单IP请求密度 | 200 × 6 ÷ 500 = 2.4次/分钟 |
2.4次/分钟处于低风险区间，IP总量暂时不是瓶颈。如果此时成功率仍然低于90%，问题大概率出在后面两层：分配策略或IP质量。
反过来，如果计算结果超过10次/分钟，优先考虑两个方向：降低每线程请求频率，或增加可用IP数量。增加IP数量是有效手段，但只在密度确实超标时才值得投入。
IP数量够用但还是失败，分配策略哪里出了问题？
IP总量够用不代表每个线程都能拿到"好IP"。分配策略不合理会导致部分线程反复拿到同一批IP，而另一部分IP闲置浪费。
三种常见的分配策略问题：
问题一：线程与IP绑定不均匀。 200个线程分配500个IP，理想状态是每个IP被2-3个线程共享。但如果分配算法是简单的哈希取模，某些线程可能集中映射到同一小批IP上。排查方法是统计每个IP在单位时间内被请求的次数分布，看是否存在"热点IP"。
热点IP的判断标准：
| 指标 | 正常 | 异常 |
|---|---|---|
| 单IP被请求次数的标准差 | 占均值的30%以内 | 超过均值的50% |
| 请求次数最高的IP vs 最低的IP | 差距 < 3倍 | 差距 > 5倍 |
| 前10% IP承载的请求占比 | < 20% | > 40% |
问题二：IP轮换与线程生命周期不同步。 很多采集框架的线程池是长连接复用模式，线程创建后持续运行数小时。如果代理IP的存活周期是5分钟，但线程每次请求都从同一个代理入口获取IP，可能出现"线程还活着但IP已经被回收"的断裂。表现为部分线程在运行一段时间后成功率突然归零。
排查方法：记录每个线程每次请求实际使用的出口IP，画出"线程-IP"的时间线。正常情况下，每个线程的IP应该随时间平滑切换。如果某个线程的IP长时间不变或突然全部失败，说明轮换机制与线程模型不匹配。
问题三：IP池的地域分布与目标站点不匹配。 以招投标数据采集为例，目标站点可能按省份划分数据接口。如果500个IP中80%集中在同一省份，那些访问其他省份接口的线程实际可用IP远少于总量。
排查方法：按目标站点的地域维度统计IP分布，确认每个地域分区的IP覆盖是否均衡。
单IP存活周期和任务耗时怎么匹配？
这是多线程场景里最容易被忽略的排查维度。
核心矛盾： 如果单个采集任务的完成耗时超过了IP的存活周期，任务会在中途因为IP切换而中断。在APP大数据分析场景中，一次完整的数据拉取可能涉及登录、翻页、数据提取三个步骤，总耗时3-5分钟。如果IP存活周期只有1分钟，每次任务至少经历3次IP切换，每次切换都有中断风险。
匹配度计算：
匹配度 = IP存活周期 ÷ 单任务平均耗时| 匹配度 | 评估 | 建议 |
|---|---|---|
| > 2.0 | 充裕 | IP存活周期远大于任务耗时，无需调整 |
| 1.2-2.0 | 合理 | 有一定余量应对网络波动 |
| 0.8-1.2 | 紧张 | 频繁出现任务尾部IP切换导致的中断 |
| < 0.8 | 不匹配 | 需要选择更长存活周期的IP资源 |
排查步骤：
- 统计单任务从发起到完成的耗时分布，取P95值作为基准
- 确认当前代理IP的实际存活周期，注意"实际"而非"标称"，有些服务的实际存活比标称短
- 计算匹配度，低于1.2的场景需要调整IP周期档位或拆分任务步骤
完整排查流程怎么跑？
把前面四个维度串成一个从粗到细的排查决策树：
多线程采集频繁失败
│
├── 第一层：失败分类
│ ├── 连接被拒 + 配额耗尽提示 → 直接指向IP数量不足 → 扩容
│ └── 其他类型 → 进入第二层
│
├── 第二层：单IP请求密度检查
│ ├── 密度 > 10次/分钟 → 降频或扩容
│ └── 密度 < 10次/分钟 → 进入第三层
│
├── 第三层：分配策略检查
│ ├── 热点IP存在 → 优化分配算法
│ ├── 轮换与线程不同步 → 调整轮换机制
│ └── 地域分布不均 → 补充特定地域IP
│
└── 第四层：存活周期匹配度检查
├── 匹配度 < 1.2 → 选更长周期档位或拆分任务
└── 匹配度 > 1.2 → 排查目标站点侧因素每层排查的耗时预估：
| 排查层 | 需要的数据 | 预计耗时 |
|---|---|---|
| 第一层：失败分类 | 采集日志中的HTTP状态码和错误类型 | 30分钟 |
| 第二层：密度检查 | 线程数、请求频率、可用IP数 | 15分钟 |
| 第三层：分配策略 | 每个IP的请求次数分布统计 | 1-2小时 |
| 第四层：周期匹配 | 任务耗时分布、IP实际存活时长 | 1小时 |
多数情况下，第一层和第二层就能定位问题。只有在密度正常、分类无明显倾向时，才需要深入到第三层和第四层。
一个容易犯的错误：跳过前三层直接加IP。 如果问题出在分配策略的热点IP上，加再多IP也只是让热点更热。先排查再扩容，是控制成本的基本原则。
FAQ
Q：怎么快速拿到"单IP请求密度"这个数据？
在采集框架的代理中间件层加一行日志，记录每次请求使用的出口IP和时间戳。跑10分钟后导出日志，按IP聚合统计每分钟请求次数即可。多数主流采集框架都支持在中间件层插入自定义日志逻辑，改动量通常不超过10行代码。
Q：线程数和IP数的合理比例是多少？
没有固定比例，取决于目标站点的频率控制策略。对于频率控制严格的站点，建议线程与IP的比例不超过1:1，即每个线程独占一个IP。对于频率控制宽松的站点，3-5个线程共享一个IP通常没有问题。用单IP请求密度公式反推，把密度控制在目标站点的安全阈值以下。
Q：怎么区分是代理IP的问题还是目标站点的问题？
用同一批IP请求httpbin.org或自建echo服务器做对照测试。如果对照测试成功率正常但真实目标站点失败率高，问题在目标站点侧的频率控制策略，而非代理IP本身。如果对照测试也失败，问题在代理服务侧。
Q：成功率从高到低逐渐下降，是IP被"记住"了吗？
大概率是。目标站点的频率控制机制通常会维护一个IP行为画像，短期内高频请求的IP会被逐步降权。解决方式是缩短IP的使用时长，在被标记之前主动轮换。具体的安全使用时长需要通过小批量测试摸索，不同站点差异很大。
Q：加IP和降线程数哪个更划算？
从单IP请求密度公式看，降线程数和加IP在数学上等效。但从成本角度看，降线程数是免费的，加IP要花钱。先评估当前线程数是否真的必要：如果200个线程中有50个在等待IO而非真正执行采集，把线程数优化到150就等于免费"增加"了25%的IP容量。
Q：多线程采集的IP消耗量怎么提前预估？
反推公式：所需IP数 = 总线程数 × 每线程每分钟请求数 ÷ 目标密度阈值。比如100个线程、每线程每分钟请求6次、目标密度控制在3次/分钟以内，则所需IP数 = 100 × 6 ÷ 3 = 200个。再乘以1.3的冗余系数，得出至少需要260个同时可用IP。注意是"同时可用"而非"总购买量"，IP池的实际在线率需要提前确认。
