高并发数据采集下的代理IP架构：从单机到集群，哪一步该加什么

不要一上来就搭集群

我见过不少团队的做法：任务还没跑起来，先花两周搭了一套 Redis 集群 + 消息队列 + 独立调度服务 + 监控大盘的代理架构。结果日均请求量只有几千——架构的运维成本比采集本身还高。

反过来也有团队一直用单机脚本跑，日均请求量已经上了十万、成功率掉到 60%，才开始想"是不是该换架构了"——这时候积累的技术债务已经很重，改造成本远高于从合适的时机做增量演进。

合理的做法是：按请求量级和业务复杂度分阶段演进，每个阶段只解决当前瓶颈，不提前过度设计。

阶段一：单机单脚本（日均 < 5 万请求）

典型场景： 一个 Python 脚本 + requests 库 + 一个代理 IP 列表，跑一个采集任务，目标站 1-2 个。

代理架构： 最简单的形态——代理列表存在本地文件或配置里，脚本启动时加载，按轮询或随机方式使用。

 import random
 import requests
 ​
 proxies_list = [
     "http://ip1:port1",
     "http://ip2:port2",
     # ...
 ]
 ​
 def get_with_proxy(url):
     proxy = random.choice(proxies_list)
     return requests.get(url, proxies={"http": proxy, "https": proxy}, timeout=10)

这个阶段的核心问题：

根本没有 IP 健康管理。某个 IP 挂了，你不知道——它继续被选中，继续失败，拉低整体成功率。

没有失败反馈。脚本里的错误处理通常是 try/except 然后 continue，不会把失败信息反馈给代理选择逻辑。

什么时候该演进： 当你发现成功率不稳定、需要频繁手动删除失效 IP、或者开始有第二个采集任务需要共用代理时。

演进方向： 加一个最简单的代理管理层——不需要 Redis，不需要独立服务，在脚本内部加一个带评分的代理选择器就够了。

 class SimpleProxyPool:
     def __init__(self, proxies):
         self.proxies = {p: 100.0 for p in proxies}  # ip: score
 ​
     def get(self):
         # 按评分加权随机
         total = sum(self.proxies.values())
         if total == 0:
             return None
         r = random.uniform(0, total)
         cumulative = 0
         for proxy, score in self.proxies.items():
             cumulative += score
             if r <= cumulative:
                 return proxy
         return list(self.proxies.keys())[0]
 ​
     def feedback(self, proxy, success):
         if proxy not in self.proxies:
             return
         if success:
             self.proxies[proxy] = min(self.proxies[proxy] + 2, 100)
         else:
             self.proxies[proxy] *= 0.7
             if self.proxies[proxy] < 5:
                 del self.proxies[proxy]  # 淘汰

这个改动只需要几十行代码，但效果显著：坏 IP 会被自动降权和淘汰，好 IP 会被更多地使用。

阶段二：单机 + Redis 代理池（日均 5-30 万请求）

典型场景： 1-3 个采集任务并行跑，可能用了 Scrapy 或 asyncio，单机并发 20-50。代理 IP 数量从几十个增长到几百个。

演进触发条件：

多个采集任务需要共享代理池——脚本 A 和脚本 B 同时跑，如果各自维护独立的代理列表，IP 使用状态不一致。

代理 IP 从上游接口动态获取——不再是固定列表，需要定期刷新，新 IP 要验证后再入池。

开始需要按目标站隔离代理（脚本 A 打目标站 X、脚本 B 打目标站 Y，不想互相干扰）。

代理架构： Redis 成为代理池的中心。Sorted Set 存 IP 和评分，Hash 存元数据，Set 存黑名单。所有采集脚本连同一个 Redis 实例。

这个阶段要做的关键改造：

把代理池从脚本内存搬到 Redis。 所有脚本共享同一个 Redis 代理池，IP 的评分、使用记录、黑名单都在 Redis 里——任何一个脚本发现某个 IP 失效，其他脚本立刻能看到。

加一个独立的健康检测进程。 不要让每个采集脚本自己做健康检测（会重复检测、浪费资源、产生竞态）。单独跑一个进程，每 5-10 分钟扫描 Redis 里所有 IP，更新评分，淘汰坏 IP。

加水位监控。 一个简单的 cron 任务，每分钟检查 Redis 里 ZCARD 的值，低于阈值时触发 IP 补充（调用上游接口获取新 IP、走入池验证流程）。

这个阶段的典型问题：

单机并发上限。Python 的 GIL 限制了 CPU 密集型任务的并发能力。如果你的采集逻辑包含大量 HTML 解析，单进程的并发瓶颈在 30-50 左右。解决方案是用多进程（multiprocessing）或改用 asyncio + aiohttp。但这还是单机范畴。

Redis 单点故障。这个阶段 Redis 通常是单实例，挂了整个代理池不可用。如果业务允许短暂中断（几分钟），Redis 重启后重新跑一次 Fetch + 验证就能恢复。如果不允许中断，加 Redis Sentinel 做主从自动切换。

什么时候该演进： 当单机的 CPU、内存、出口带宽中任何一个成为瓶颈，或者你需要从多个不同地域的出口发请求时。

阶段三：多机 Worker + 中心调度（日均 30-100 万请求）

典型场景： 3-10 台机器组成 Worker 集群，共享 Redis 代理池和请求队列。可能已经用了 Scrapy-Redis 或自建的分布式任务调度。

演进触发条件：

单机出口带宽不够——一台机器的千兆网卡跑满了也只有 ~120MB/s 的下载能力。

需要多地域出口——比如采集任务要求从不同城市或国家发请求，单机只能从一个出口发。

单机故障影响全局——一台机器挂了，所有采集任务停。

代理架构的关键变化：

代理调度要加锁。 多个 Worker 同时从 Redis 代理池取 IP，需要防止同一个 IP 被多个 Worker 同时用在同一个目标站上。用 Redis 的 SET NX EX 做分布式锁，锁的粒度是 ip + domain。

代理评分要聚合。 Worker A 报告某个 IP 成功，Worker B 报告同一个 IP 失败——评分更新不能各自为政。两种方案：一是所有 Worker 直接写 Redis（用 ZINCRBY 原子操作，天然支持并发），二是让 Worker 把反馈发到消息队列，由一个独立的评分聚合服务统一更新。方案一简单够用，方案二在 Worker 数量超过 20 台时更可控。

健康检测要防重复。 阶段二的独立检测进程在这里还是跑一个就够——它扫描 Redis 里所有 IP 做检测，和 Worker 数量无关。但要注意：如果你部署了多个检测进程副本（为了高可用），需要用分布式锁保证同一时间只有一个在跑。

 def run_health_check_with_lock(rdb, pool_key):
     lock = rdb.lock("health_check_lock", timeout=600, blocking_timeout=5)
     if lock.acquire(blocking=False):
         try:
             do_health_check(rdb, pool_key)
         finally:
             lock.release()
     else:
         print("Another checker is running, skip.")

这个阶段的典型问题：

Worker 之间的请求分配不均。如果用 Scrapy-Redis，请求分配是"谁先 POP 谁拿"，快的 Worker 多干、慢的少干。如果某些 Worker 因为网络环境差导致成功率低，它们会消耗大量代理 IP 但产出少。解决方案：监控每个 Worker 的成功率，成功率低于阈值的 Worker 自动降低请求获取频率。

跨地域部署的时钟同步。如果 Worker 分布在不同地域，Redis 的 TTL 和分布式锁的超时依赖系统时钟。时钟不同步可能导致锁提前释放或过期判断出错。确保所有机器都配置了 NTP。

阶段四：完整的代理网关（日均 > 100 万请求）

典型场景： 大规模数据采集团队，10+ 台 Worker，多个业务线共用代理基础设施，需要精细的流量控制、成本统计、权限管理。

演进触发条件：

需要统一的代理接入层——不同业务线的采集脚本使用不同的语言和框架（有用 Python 的、有用 Go 的、有用 Node.js 的），不可能每种语言都实现一套 Redis 代理调度逻辑。

需要成本核算——按业务线统计代理 IP 的消耗量和成本，谁用了多少、花了多少。

需要限流和权限——业务线 A 每天最多用 50 万个请求的代理配额，超了就排队。

代理架构： 在 Worker 和 Redis 代理池之间加一层 代理网关（Proxy Gateway）——一个独立的 HTTP 服务，Worker 的所有请求先发到网关，网关负责：选 IP、加速率限制、记录使用日志、返回代理。

Worker 侧的改造非常简单：把代理地址从具体的 IP:PORT 改成网关地址。Worker 不再直接操作 Redis，不需要知道代理池的内部逻辑。

 # Worker 只需要知道网关地址
 proxy = "http://proxy-gateway.internal:8080"
 requests.get(target_url, proxies={"http": proxy, "https": proxy})

网关内部的核心模块：

 请求接入 → 鉴权(API Key / 业务线标识)
          → 限流(令牌桶，按业务线独立计数)
          → 选IP(从Redis池取，带评分、隔离、冷却逻辑)
          → 转发请求
          → 接收响应
          → 更新IP评分
          → 记录日志(业务线、目标站、IP、状态码、延迟、成本)
          → 返回响应给Worker

网关可以用 Go 或 OpenResty（Nginx + Lua）实现，性能要求是能扛住所有 Worker 的并发——日均百万请求大约是每秒 12-15 QPS（均摊），峰值可能到 50-100 QPS，Go 的 net/http 或 OpenResty 都轻松撑住。

这个阶段要特别注意的事：

网关本身不能成为单点。至少部署 2 个实例，前面挂负载均衡。

日志量会很大。每天百万条请求日志，存数据库太贵，建议写到文件 + 定期归档，或者写到 ClickHouse 这类列式数据库。

成本统计口径要提前定义。按请求数计费、按 GB 计费、按成功请求计费——不同口径差异很大，提前和业务方对齐。

各阶段速查表

演进过程中最常犯的三个错误

错误一：跳级。 日均 3 万请求就上代理网关。网关的开发和运维成本远高于直接在脚本里加个 SimpleProxyPool 类。每个阶段的方案都是为对应量级优化的，跳级只会增加不必要的复杂度。

错误二：不做水位监控就上多 Worker。 多 Worker 消耗 IP 的速度是单机的 N 倍。如果没有水位监控和自动补充机制，池子会在高峰期迅速被掏空，所有 Worker 同时取不到 IP，采集全部停转。

错误三：只看成功率，不看单位成本。 阶段三以后，成功率 95% 但每个成功请求的代理成本是 0.1 元，和成功率 85% 但单位成本 0.03 元——哪个更好取决于你的业务。演进架构时要同步建立成本统计口径，不能只盯着成功率。

FAQ

Q：从阶段二到阶段三，是不是必须用 Scrapy-Redis？

不是。Scrapy-Redis 是一种方案，但不是唯一的。如果你不用 Scrapy（比如用 asyncio + aiohttp，或者用 Go 写采集器），可以自己实现分布式任务分发——用 Redis List 做队列、用 Pub/Sub 或消息队列做通知。核心是把"任务分发"和"代理调度"两个问题分开解决，不要耦合在一起。

Q：代理网关用 Go 写还是用 OpenResty？

如果团队熟悉 Go，用 Go 的 net/http + httputil.ReverseProxy，开发快、调试方便。如果团队有 Nginx 运维经验，OpenResty 的 Lua 脚本可以热更新，不需要重启网关就能改调度逻辑。日均百万级的流量两种方案都扛得住，选团队更熟悉的。

Q：Redis 在哪个阶段需要上集群？

阶段三通常不需要——Redis 单实例的吞吐（10 万+ QPS）远超代理调度的需求。阶段四如果代理池规模超过 10 万个 IP，或者你把所有业务线的日志也存在 Redis 里，可能需要上 Redis Cluster。但更常见的做法是日志不走 Redis（写 ClickHouse 或文件），Redis 只存代理池状态，这样单实例基本够用到日均千万级。