票务平台反爬升级，我踩的第一个坑
上个月，某头部票务平台突然升级了反爬策略：同一IP单日请求超过200次直接拉黑，更狠的是，如果检测到IP在短时间内切换（小于30秒），会被标记为“机器行为”并永久封禁账号。我的抢票系统第一天就崩了——3000个共享代理IP在10分钟内被封了87%，7个账号被永久封停。
说实话，当时差点被老板骂到怀疑人生。但冷静下来复盘，我发现问题不在共享代理IP本身，而在调度架构设计：没有故障转移、负载均衡全靠轮询、监控告警为零。本文就复盘这次重构过程，重点讲如何设计一个能抗百万级并发、封号率降低80%的代理IP调度架构。
架构设计的三个核心模块
1. 故障转移：让“死IP”自动下架
共享代理IP的存活率不是100%，哪怕服务商宣称99.9%可用率，实测中总有5-8%的IP在某个时间段失效（比如被目标网站封禁、超时或DNS污染）。我的做法是引入健康检查队列：
- 每个代理IP分配一个协程，每隔60秒发送一次握手请求到目标网站（如票务平台的登录页），响应时间超过3秒或状态码非200则标记为“可疑”。
- 连续3次健康检查失败，自动移出可用池，并触发服务商API重新提取新IP补充。
- 故障IP放入“冷却队列”，等待30分钟后再尝试复活——因为有些临时封禁会过期。
实现代码片段（Go语言）：
type ProxyHealth struct { ip string failCount int lastCheck time.Time}func healthCheck(p *ProxyHealth) bool { resp, err := http.Get("https://target.com/login") if err != nil || resp.StatusCode != 200 { p.failCount++ return false } p.failCount = 0 return true}
这套机制上线后，因为使用“死IP”导致的重试时延降低了92%，封号率从87%降到12%。
2. 负载均衡：告别轮询，拥抱“最小压力策略”
轮询分配IP看起来公平，但票务系统有个特点：某些IP可能在短时间内被多个请求命中（如果并发高且IP池小），目标网站会把该IP视为爬虫。我们改用最小请求数（Least Connections）算法：每次分配前查询该IP当前正在处理的请求数，选择并发量最小的那个。
参数调优：
- 每个IP最大并发请求数设为5（基于目标网站的反爬阈值实测，超过5个并发请求时封禁概率飙升）；
- IP池维护1000+个活跃IP，确保任意IP的当前请求数<5；
- 如果所有IP的当前请求数都达到上限，则启用等待队列，设置超时500ms，超时后返回429错误给业务层，避免死循环。这里我踩过一个坑：没有设超时，结果所有请求都堵塞，系统OOM了。
负载均衡的收益：单IP的日均请求量从高峰期3000次降到了600次以下，目标网站的封禁阈值几乎不会被触发，封号率再降到3%。
3. 监控告警：别等到全挂了才发现
以前我的监控只有“可用IP总数下降报警”，但是当可用IP从1000降到200时，系统已经半瘫痪了。我重构了监控维度：
- 实时统计：每10秒上报可用池大小、平均健康检查延迟、最新封禁IP比例；
- 趋势告警：如果连续3分钟内可用IP下降超过15%，自动通知并触发“紧急扩容”策略——立即从服务商API提取200个新IP补充；
- 延迟抖动告警：如果平均响应时间超过800ms（正常在200ms以下），说明IP质量下降，可能被限速或污染，自动切换备用路由。
这套监控上线后，有一次票务平台突然升级验证码拦截，我们5分钟就发现IP被封速度异常，及时切换了备用通道，损失控制在0.2%的请求失败率。
实战验证：票务抢购系统连续7天压测
我把整个架构部署到生产环境，用模拟的百万级抢购场景（6万并发/秒，每请求至少5秒房态查询）跑了一周。结果如下：
| 指标 | 优化前 | 优化后 | 变化 |
|---|
| IP封禁率 | 87% | 3.2% | ↓ 96% |
| 请求失败率 | 15.3% | 1.1% | ↓ 93% |
| 平均响应时间 | 1.2s | 0.38s | ↓ 68% |
| 系统宕机次数 | 3次 | 0次 | — |
共享代理IP池用的是蚂蚁代理（mayihttp.com），配置参数：动态代理（提取后24小时有效），每次提取100个，平均延迟9ms，可用率实测99.8%。说实话，之前我担心共享代理纯净度不够，但配合上面这套调度架构后，封禁率完全可控。唯一注意：抢票高峰期建议开隧道代理（16元/天），延迟更稳定，不过成本翻倍了，看预算取舍。
如果重来，我会省掉哪些工作？
这次重构花了2周，其实有些弯路可以避免：比如一开始我手动写了IP评估脚本，后来发现直接用服务商提供的API节点结合健康检查更省事；还有负载均衡算法从加权轮询改成最小连接数时，旧代码必须全改，不如一开始就设计成可插拔模式。如果读者也在搭建自己的调度系统，建议先把健康检查、熔断、动态扩容三个基础组件写好，后面加什么策略都不慌。
最后，别迷信“独享IP一定比共享好”。在票务这种高并发抢购场景，独享IP数量有限且成本高，共享IP配上好架构反而更灵活。关键是把调度层做扎实——故障转移扛住IP失效，负载均衡减少单个IP压力，监控告警让你在翻车前及时刹车。