简介这份基于Redis的代理池服务框架压缩包面向网络爬虫、代理验证与负载均衡等场景的开发者用于解决单点代理IP不稳定、访问效率低及调度管理困难等问题。资源共43个文件整体约26KB包含35个Python脚本、3个Shell脚本、2个Markdown文档以及配置文件覆盖代理收集、验证、调度、Redis存储交互等核心模块可帮助快速搭建一套可用的代理池管理服务。包内目录结构清晰核心业务逻辑与工具脚本分离并附有启动/停止脚本和框架说明文档便于理解与二次开发。配置层支持设定Redis连接信息与运行参数验证模块可测试HTTP、HTTPS、SOCKS等多种协议调度算法会优先分配表现更优的代理IP以提升整体成功率。目前已有44人学习下载适合具备一定Python基础、希望优化代理管理与网络请求效率的开发者参考。1. 代理池这个老问题为什么偏要用 Redis 重新搭一遍框架做爬虫的人没有谁没被代理IP坑过。早晨测好的一批代理到中午就只剩一半能用贵的稳定池成本扛不住免费的又像开盲盒——今天全通明天全部超时。我见过不少团队把代理IP当消耗品随意采购结果在封控严的业务数据采集场景里一个接一个连接超时最后排查出来根本不是目标网站的问题是代理池压根没人管。这篇要拆的就是「基于Redis的代理池服务框架」这一类方案的落地路径用 Redis 做存储与调度中枢让采集、校验、淘汰、对外暴露全部自动化。它解决的是「手搓脚本测代理」这种临时方案解决不了的事——失效自动剔除、质量可打分、多业务方共享同一份代理数据。适合正在做爬虫采集、接口轮换、或想把自己的代理管理从手工 Excel 升级成服务的工程师。2. 盘活 Redis 数据类型来搭代理池五种结构的职责边界2.1 用 Hash 存代理详情为什么比存 JSON 字符串稳代理池里一条代理记录不只是「IP:端口」两个字段。协议类型是 HTTP 还是 HTTPS、来源站点、上次校验时间、连续失败次数、匿名等级这些东西都跟着一条代理走。很多第一次搭框架的人图省事直接把整个对象序列化成 JSON 塞进 Redis 的 String 里取出来再整体反序列化。数据量小的时候没问题几百条代理随便折腾一旦代理池过万每次校验只更新「连续失败次数」一个字段却要把整个 JSON 取出来解析再写回去性能损耗和并发冲突就开始冒头。用 Hash 的好处是字段独立更新。我会给每条代理分配一个唯一 key比如 proxypool:detail:{md5}然后把它拆成 host、port、protocol、source、fail_count、score 这些 field 分别存储。校验器只需要 HINCRBY 更新失败次数、HSET 更新得分不碰其他字段。另一个实在的好处是排查问题方便——RedisInsight 或 Another Redis Desktop Manager 里随便点开一条 Hash所有字段平铺在眼前不用靠脑补 JSON 里的嵌套结构。还有一点容易被忽略删除粒度。Hash 可以整体 DEL也可以单独 HDEL 掉某个失效字段而 String 只能整体覆盖。代理池里经常出现「IP 还能通但协议已经变了」的情况例如一个代理昨天还支持 HTTPS今天目标网站握手失败。这时候直接更新 protocol 这一个 field比起改整个 JSON 再写回代码更短、出错的路径更少。2.2 用 Set 去重、ZSet 调度代理池的数据组织核心代理池和普通缓存最大的不同是它需要「排序」和「范围获取」。Redis 的 ZSet 天生就是干这个的member 存代理唯一标识score 存代理质量分。校验器每次成功验证就给这条代理加分连续失败就减分。代理池对外提供代理时按分数从高到低取一条 ZREVRANGE拿到的就是当前质量最好的一条。但 ZSet 有一个天然的毛病member 是唯一的可它不提供「某个来源是否已经采集过」的判断。代理采集器每天从免费代理网站抓好几轮同一个 IP 今天出现在 A 站、明天出现在 B 站如果直接 ZADD后面的操作会把前面的覆盖或者只是更新 score导致「这个代理我到底有没有入库过」变得模糊。所以我一般会额外维护一个 Set 集合专门做去重SADD 之后如果返回 0说明是重复代理直接跳过后续流程。ZSet 的 score 设计是整个代理池的灵魂。我见过把 score 直接存「连续成功次数」的也见过直接存「Unix 时间戳」的——把最近使用时间当分数这样取出来的永远是最新代理。这两种都有道理但没法同时表达「质量好」和「新」。我会拆成两个维度一个 ZSet 存质量分另一个 Hash 存代理元数据里的 last_checked 字段。质量分负责选代理时间戳负责淘汰旧数据各管各的。2.3 用 List 做校验任务队列把分布式锁也带上代理入库后不能直接对外暴露因为还没验证过。框架里需要一条「待校验队列」采集器拿到新代理推入一个 List校验器从 List 左侧弹出逐个去目标网站验证连通性。为什么用 List 而不是直接轮询 ZSet因为 List 天然支持阻塞弹出BRPOP 可以让校验器空闲时挂起、有任务时立刻醒来不用写定时轮询逻辑Redis 连接也不会被无谓的循环查询打满。多个业务方同时取代理的时候还要考虑一个问题别让 10 个业务方把同一条刚入库的新代理抢去验证验证完又同时写回 ZSet分数直接被覆盖成同一个值——这属于典型的并发写冲突。常见做法是给校验任务加一把 Redis 分布式锁用 SETNX 或者 Lua 脚本抢锁抢到锁的节点才执行这一轮的验证和打分更新。注意锁的粒度要细最好锁到单条代理的 key而不是锁整个队列否则一个代理卡住验证全队列都跟着堵车。3. 代理池服务框架落地从采集到验证再到暴露代理的最短路径3.1 模块划分采集器、校验器、API 服务怎么分工一个能跑起来的代理池服务框架最少需要三个进程角色。采集器负责从公开代理网站抓取代理做基础格式清洗后写入 Redis校验器负责消费待校验队列用真实请求验证代理能否访问目标网站更新 Hash 详情和 ZSet 分数API 服务负责对外提供 HTTP 接口业务方来要代理就给一条分数最高的来报「这条代理失败了」就把分数扣掉。三个模块之间不用通信协议全部通过 Redis 解耦。采集器写队列校验器读队列API 读 ZSet——谁挂了都不影响另外两个继续工作这是把 Redis 当中间件用最大的收益。部署上三个模块可以跑在同一台机器上先验证效果之后再把校验器单独拆到多台机器横向扩容。校验器是一个无状态消费者水平扩展几乎零成本只要保证所有实例连的是同一个 Redis 实例或集群就行。3.2 代理入库的代码Python redis-py 怎么把数据写进 ZSet这里给一个最小可用的入库逻辑用 Python 的 redis-py 客户端。注意这段代码处理了「去重、详情存 Hash、调度进 ZSet、来源记录进 Set」四件事import hashlib import json import redis import time r redis.Redis(host127.0.0.1, port6379, db0, decode_responsesTrue) def gen_proxy_key(protocol: str, host: str, port: int) - str: raw f{protocol}://{host}:{port} return hashlib.md5(raw.encode(utf-8)).hexdigest() def add_proxy(proxy: dict, source_site: str) - bool: protocol proxy.get(protocol, http).lower() host proxy.get(host) port int(proxy.get(port)) key gen_proxy_key(protocol, host, port) # 1. 去重Set 里已经存在就跳过 if r.sadd(proxypool:seen:global, key) 0: r.hincrby(fproxypool:detail:{key}, duplicate_count, 1) return False # 2. 存详情Hash 各字段独立后续更新只动单字段 detail { protocol: protocol, host: host, port: port, source: source_site, added_at: int(time.time()), last_checked: 0, fail_count: 0, success_count: 0, } r.hset(fproxypool:detail:{key}, mappingdetail) # 3. 进待校验队列初始分数 0代表还没被验证过 r.zadd(proxypool:score, {key: 0}) r.rpush(proxypool:todo, key) return True这段代码的逻辑顺序是刻意的先去重再存详情最后入 ZSet 和队列。如果先 ZADD 再去重会出现 Set 里没记录、ZSet 里却已经有了脏数据的中间态。把 ZADD 放最后即使中途崩溃最多丢一条待校验任务不会污染调度表。有一个细节值得注意我在 Hash 里单独存了 success_count 和 fail_count而不是只存一个最终分数。因为分数是可以通过 Lua 脚本重算的但「成功了几次、失败了几次」这些原始数据一旦丢重算就没依据了。这也是为什么我坚持用 Hash 存过程数据、用 ZSet 只存派生数据的原因——Hash 相当于原始日志ZSet 相当于视图。3.3 校验任务消费BRPOP 阻塞队列的完整循环校验器这边用一个常驻脚本消费队列。这里不只用 BRPOP 取任务关键在后半段——取出来的代理如果验证失败要根据 fail_count 决定是「重新排队再试」还是「直接打回老家」import time import requests as req VALIDATE_URL https://httpbin.org/ip VALIDATE_TIMEOUT (3, 5) def consume_todo_queue(): while True: # 阻塞等待待校验队列超时 30 秒后循环回来继续等 item r.brpop(proxypool:todo, timeout30) if item is None: continue proxy_key item[1] detail r.hgetall(fproxypool:detail:{proxy_key}) if not detail: continue ok False try: proxies { detail[protocol]: f{detail[protocol]}://{detail[host]}:{detail[port]} } resp req.get(VALIDATE_URL, proxiesproxies, timeoutVALIDATE_TIMEOUT) ok resp.status_code 200 except Exception: ok False if ok: # 验证成功加分数、清失败计数、刷新最后验证时间 r.zincrby(proxypool:score, 10, proxy_key) r.hset(fproxypool:detail:{proxy_key}, mapping{ last_checked: int(time.time()), fail_count: 0, }) else: # 验证失败失败计数 1按失败次数决定是重试还是淘汰 fail_cnt r.hincrby(fproxypool:detail:{proxy_key}, fail_count, 1) if fail_cnt 3: remove_proxy(proxy_key) else: # 重新排到队尾但这里刻意加一个延迟避免立刻再次验证 r.zadd(proxypool:todo_delay, {proxy_key: time.time() 60})看到没失败 3 次以上的代理我不会直接删 ZSet——因为代理价值不只取决于它是否存活还要考虑它来自哪个采集源。如果某个来源站连续贡献了 10 个「验证失败」的代理那我应该把整个采集源降权甚至拉黑而不是逐个删代理。代理池的「治理」落到源头才是高效的。校验超时参数这里我给的是 3 秒连接、5 秒读取这是爬虫场景里比较平衡的配置。太短会把慢速但真正可用的代理误杀太长会让校验器吞吐量暴跌一个代理验证卡了 30 秒整个消费循环就堵住了。如果你验证的代理数量大建议把超时压到 2 秒同时把队列消费者数量从 1 个扩到 3 个——Redis 的 BRPOP 天然支持多个消费者同时阻塞在同一个 List 上不会重复消费这也是 List 做任务队列相比 ZSet 的一个明显优势。4. 调度打分与淘汰策略让代理池自己长出一套优胜劣汰4.1 打分规则成功率、连续失败、来源可信度三个维度加权代理池跑起来之后你很快就会遇到下一个问题分数只有「成功 10、失败 0」两条规则感觉不够用。比如一个来自免费站的代理今天通了 30 次明天突然连续失败 5 次按上面的逻辑它要被删了但它之前明明很稳定——直接删掉是不是太武断我会把打分拆成三个维度成功率最近 20 次校验里成功占比、连续失败次数代表当前的即时状态、来源可信度代表这个采集源长期的历史表现。三者的权重可以按你的业务场景调如果代理主要用于短时突发采集来源可信度权重调低如果代理是长期稳定跑量来源可信度权重调高。分数公式不必搞太复杂线性加权就够了score success_rate * 100 source_score * 20 - fail_count * 5这个公式的意思很简单成功率是主要质量指标满分 100来源可信度是一个 -10 到 10 的调整项影响范围在 ±200连续失败次数是惩罚项每失败一次扣 5 分。当分数被扣到负数对外取代理时 ZREVRANGE 自然取不到它——它还在池里但已经「沉底」等它下一次验证成功再被捞起来。这套规则的好处是「可解释」。任何人问「这条代理为什么分数是 83」你可以直接拆给他看成功率 90% 得 90 分来源可信度 5 得 100 分有过 7 次连续失败扣 35 分加在一起 155——等等你说 155那就说明公式里还有另一个维度在起作用例如匿名等级加分。总之规则维度不要超过 4 个超过 4 个之后你根本没法靠直觉判断一条代理的死活调试成本成倍上涨。4.2 原子调度用一段 Lua 脚本同时完成取代理和降权代理池对外的 API 如果只是单纯 ZREVRANGE 取一条分数最高的代理业务方拿走后这条代理可能在下一秒就被另一个业务方取走——两个爬虫共用一个代理 IP轻则目标网站限制重则直接封掉这个代理。解决思路是把「取出即降权」做成原子操作避免同一时刻并发取出同一条代理。Redis 的 Lua 脚本是个好工具它可以保证一个脚本内所有命令在执行期间不被其他命令插入天然避开竞态。我的调度脚本核心逻辑是这样-- 参数KEYS[1]分数ZSet, KEYS[2]待校验队列, ARGV[1]取出的最低分数 local used_key redis.call(zrevrange, KEYS[1], 0, 0, WITHSCORES) if not used_key[1] then return end -- 取出来之后马上降权防止同一时刻被其他人再次取走 redis.call(zadd, KEYS[1], used_key[2] - 20, used_key[1]) return used_key[1]注意这段脚本的关键点ZREVRANGE 拿到当前最高分的代理然后立刻用 ZADD 把它的分数减 20。由于整个操作在 Lua 脚本里是原子的两个并发请求不可能同时拿到同一条代理——第二个请求 ZREVRANGE 时这条代理的分数已经被减掉 20可能掉出顶部位置。这个「取出即降权」的手法让同一条代理在单位时间内不会被不同业务方反复使用同时又不至于直接把它踢出池子。关于减多少分合适我一般用「20」作为初始值。原因是它和成功加 10 分对应意味着「每被取用两次就需要一次成功验证来补回分数」。如果你的代理池里可用代理很多想让每条代理被取用的频率更低可以把降权值调到 30 或 40。注意如果降权值调太高一条代理刚被取用就沉底了下次业务方取代理时可能会取到质量更差的那一批——这是一个需要根据业务跑量节奏反复调参的平衡点。4.3 过期与淘汰让 Redis 的 TTL 和「缓存治理」思路帮代理池自动清垃圾ZSet 会一直保留成员除非你手动删除。这意味着即使我们通过降权让垃圾代理沉底它们依然占着 ZSet 的内存而且 ZREVRANGE 偶尔会把它捞出来给业务方造成一次「假死」体验。代理池里垃圾代理的清理常见做法是给每条代理的 Hash 设置一个过期时间到期自动消失再配一个定时任务把已经消失代理对应的 ZSet 成员也清掉。我给代理设置的 TTL 通常是 15 分钟。原因是大多数公开代理的存活周期在 10 到 30 分钟之间设置 15 分钟可以保证「一个代理最后一次成功校验之后如果 15 分钟内没有任何业务方调用它就会被自动遗忘」。注意 TTL 必须在每次成功校验时刷新否则一条好代理会被当成僵尸清掉SETEX proxypool:detail:{key} 900 value但这带来一个新问题Hash 可以 TTL 自动过期ZSet 的成员却不会跟着自动消失。每条代理在 ZSet 里还有一个分数成员过期后依然残留在内存里。所以我每周跑一次清理脚本用 ZSCAN 遍历 ZSet对每个成员去查对应的 Hash 是否还存在不存在的直接从 ZSet 里 ZREM 掉。ZSCAN 而不是 KEYS是因为代理池上了万条之后 KEYS 命令会直接卡死 Redis 主线程这在 Redis 缓存治理里是基本功但代理池场景特别容易踩——因为 ZSet 天然适合存代理而 ZSet 越大你越容易写出性能灾难级的 KEYS 扫描。清理频率不用太高每天凌晨业务低峰期跑一次就够了。清理脚本本身也要注意心法每次 ZSCAN 用 COUNT 控制一次遍历数量比如 500 条处理完之后 sleep 0.1 秒再继续避免把 Redis 的 CPU 打满。这不是玄学是代理池跑久了之后最常见的性能杀手。5. 代理池避坑指南五条踩出来的硬经验5.1 现象代理池跑一天后 ZSet 分数全乱源头是并发写代理池上线第一周我遇到过分数全部变成 9999 的诡异故障。排查半天发现是多个校验器实例同时验证同一条代理每个实例都执行 ZINCRBY 加分同一时刻 5 个实例同时加 20分数瞬间暴涨。后续所有业务方拿到的都是同一批高分代理池子里的其他代理被活活饿死。原因就是校验器扩容后没有做并发控制。校验任务在处理前没有确认「这条代理是否正在被其他实例校验」两个实例从 BRPOP 里同时取到一条任务BRPOP 本身不会重复交付但校验器消费完队列之后代理重新被 ZADD 到待校验队列时可能被另一个实例再次取走就会造成重复验证和重复加分。解决方式是两层的第一层校验器拿到代理后先检查 Hash 里的 lock 字段用 SET NX EX 设置一个 60 秒的锁拿不到锁就跳过第二层如果同一条代理在两分钟内被验证了三次以上就不再给它加分只更新 last_checked 时间。这两个措施落地之后分数乱跳的问题再没出现过。5.2 现象代理验证成功但业务方实际用不了目标网站判定标准不一致最经典的翻车现场。我用 httpbin.org 做验证目标代理验证全部通过结果业务方拿这些代理去请求目标网站大批连接超时。原因在于 httpbin.org 对代理的判定极宽松只要代理能建立 TCP 连接就算通而真实业务目标网站有 TLS 指纹校验、有 cookie 会话校验、有频率限制一条代理在 httpbin 上通了在目标网站上可能连握手都过不去。解决思路是分级验证采集入库的代理用轻量目标做「存活验证」只验证 TCP 连通业务方实际使用前再到目标网站做一次「业务验证」通过的直接加分不通过的直接淘汰。业务验证的频率不用太高每个业务场景每 5 分钟验证一次就够了不然目标网站的请求量会被代理池的验证流量拖垮。另外验证目标和业务目标最好独立——如果只有唯一一个验证目标它挂了你的整个代理池也会误判为「全军覆没」。5.3 现象代理获取接口越来越慢Redis 连接被打满代理池对外暴露的 HTTP API 每被调用一次就要执行 ZREVRANGE 一次。本来这是很轻量的操作但业务方把获取代理的接口写成了循环——每发一次请求都来要一条新代理QPS 一高Redis 的连接数直接飙到上千。Redis 默认连接数是 10000 不假但每条连接都要建 TCP、都要占用内存连接一多整个实例响应延迟跟着上涨。这件事的坑不在 Redis 配置而在业务方行为。我会在代理池的 API 层做一层本地缓存同一个业务方在 5 秒内重复请求直接返回上一条代理不穿透到 Redis。同时在 redis-py 客户端里强制使用连接池把最大连接数控制在 50 以内超出后请求排队等待而不是新建连接。代理池本身是一个低频服务正常业务方每 10 秒拿一条代理就够用了接口响应慢十有八九是连接管理的问题不是 Redis 本身的问题。5.4 现象重启后丢了一部分代理Redis 持久化配置没跟上我犯过一个很低级的错误。本地测试用默认的 Redis 配置跑得很欢部署到生产时忘了改持久化策略结果机器在凌晨因为内存不足被系统 OOM kill 后重启代理池里的数据全没了——因为默认配置下 Redis 的 RDB 快照频率是「900 秒内至少 1 次写」代理池这种写量不小的服务很容易在两三个小时里都不满足快照条件一重启就回到 N 小时前的状态。现在我的标配是 AOF everysec。AOF 每秒写一次日志最多丢一秒的数据重启后最多回退一秒代价是磁盘写入会多些流量。代理池这种「数据量不大但写入频繁」的服务非常适合 everysec它既能保证 TTL 过期、ZSet 分数、Hash 字段这些细节全部可恢复又不会像 always 模式那样把磁盘 IO 拖垮。另外生产环境一定不要用 Redis 的默认内存淘汰策略代理池要设置 maxmemory-policy 为 noeviction否则内存满了 Redis 会随机淘汰 key你的代理数据被当成普通缓存给清掉。5.5 现象多实例部署后采集器重复抓到同一个来源站采集器如果有多台实例同时在跑同一个免费代理网站会被多个实例重复抓取每台实例都把同一批代理往 Redis 里塞。虽然 Set 去重能挡住一部分但去重是在写入时执行的采集过程本身重复耗费了大量网络请求流量和解析 CPU。我在采集器这边也加了分布式锁但锁的粒度是「采集源 时间窗口」。比如某个免费代理网站每 10 分钟更新一次列表锁就设计成 source:free_ip_site_A 5 分钟窗口每 5 分钟内只允许一台实例抓取一次。抢锁用 SETNX EXPIRE不需要引入额外组件。这个坑很隐蔽因为单实例模式下根本不会触发只有扩容到多实例才暴露——程序员最容易忽略的「看着能跑一扩就死」类型。6. 代理池上线前最后一步用模拟爬虫流量验证调度是否合理框架搭好、代码上线不代表它能扛住真实业务。我习惯在正式接入前跑一轮「模拟爬虫压测」写一个脚本模拟 20 个并发爬虫任务每个任务每 5 秒从代理池取一条代理用这条代理请求目标网站记录成功率和单次平均响应时间。压测跑 30 分钟重点看三个指标。第一看代理的平均使用次数。如果一条代理在 30 分钟内被取用超过 30 次说明调度降权力度不够业务方容易集中在少数高质量代理上如果平均使用次数低但成功率也低说明降权太狠好的代理被雪藏了。第二看分数分布的变化曲线——通过 ZRANGE 拿出全部代理分数算一下分布区间高质量代理是否集中在顶部、垃圾代理是否稳定沉底。第三看待校验队列的长度是否持续堆积如果堆积超过 500 条说明校验器消费速度跟不上采集速度需要扩校验器实例。这里有一个我后来才加上的技巧在 ZSet 里预置一个「最低分保留位」。具体做法是每轮压测结束手动把表现最差的 10% 代理分数统一压到一个负数区间而不是直接删掉。这样做的意义是保留它们的 Hash 详情方便之后复盘它们「为什么差」——是来源站质量普遍低还是某个具体时间段的验证环境出过问题。代理池最珍贵的数据不是那些活着的代理而是那些死掉的代理留下的历史记录它们能反推出采集源的优化方向。用 Redis Desktop Manager 这类可视化工具直接观察代理池的分数分布是最直观的调参方式。我每次压测结束都会打开客户端看一遍 ZSet 的分数列表再对比压测日志。分数分布异常通常一眼就能看出来要么全挤在 90 分往上要么全部负数这两种情况都说明打分规则需要重新调。最终我给代理池定了一个规矩每个代理的分数必须能让人在三秒内看懂它「为什么是现在这个状态」任何需要翻日志才能解释的分数模型对一线排查的人来说都是负担。如果你准备开始搭建议先把第 2 章的数据结构设计看懂再用第 3 章的代码跑通最小闭环最后把第 4 章的调度脚本和 TTL 策略接进去。这个方向值得投入的时间大概在三到五天做完以后你会发现自己再也不想回到「手工测代理、Excel 记录」的状态了。希望帮到你。本文还有配套的精品资源点击获取