Redis代理IP池怎么搭？从资源索引、租约到过期清理的实战设计

用 Redis 搭代理IP池，难点不在“把 IP 放进列表”，而在多个 Worker 同时领取时不重复分配、失败后不立即回流、过期资源能彻底清掉，并且每次状态变化都能复盘。如果只有一个 List 做 LPUSH/BRPOP，项目刚启动时看似够用，等并发、地区和会话要求增加，就容易出现资源串用、死 IP 循环和统计失真。

本文讨论自有系统、公开许可数据或已获授权的业务。Redis代理IP池只负责资源管理与调度；遇到 401、403、429、验证码或权限提示，应按目标端规则暂停、降速或人工核对，不能把不断换出口当成默认处理方式。

先把一条资源拆成元数据、索引和租约

不要把地址、账号、健康分和任务状态拼成一个字符串。更稳妥的做法是给每条资源分配内部 proxy_id，再拆成三类键：

认证信息不要直接写入普通 Hash、任务消息或日志，可以只保存密钥引用，由执行端在授权范围内读取。完整系统还应把提取、校验、调度和监控分层，相关边界可参考代理IP池架构设计。

可用队列用 Sorted Set，但不要只看一个健康分

Redis Sorted Set 适合维护可分配索引。分值可以综合最近探测结果、连续成功次数、延迟分档和失败惩罚，但不要把不同目标、地区和时间段的结果混成一个“全局可用率”。同一资源访问健康检查地址成功，不代表特定授权业务一定成功。

建议按资源类型或地区建立小而清晰的索引，例如可用、观察和冷却三组；任务申请时先匹配协议、地区、有效期和授权范围，再比较分值。业务线程只拿到符合条件的少量候选，不应扫描整个池。更细的任务分级与反馈口径，可结合爬虫IP池调度策略设置。

领取必须把“选中”和“加租约”做成一个原子动作

多 Worker 场景最常见的错误，是先查询高分资源，再单独写租约。两个进程可能在这两步之间拿到同一条记录。应使用 Lua 脚本或 Redis Functions，把读取候选、检查租约、创建带 TTL 的租约以及移出可用索引放进一次原子执行。

租约 TTL 要略长于单次任务的最长允许时长，并保留主动归还接口。Worker 完成后回传网络结果、HTTP 状态、业务断言和耗时：成功资源重新评分后回到可用组；连接超时进入短冷却；认证或白名单错误进入配置异常；权限、限频和验证码类结果停止自动重试。Worker 意外退出时，租约到期可释放资源，但释放前仍要检查资源本身是否已过期。

冷却队列的分值应是“下次可检查时间”

失败资源不要立刻塞回可用队列。可以用另一个 Sorted Set 保存 next_probe_at，后台任务只取分值小于当前时间的成员做有限探测。连续失败次数越多，冷却时间越长；达到上限后转入观察或人工检查，而不是无限循环。

探测也要有预算。每轮限制数量、并发和超时，避免资源供应异常时健康检查本身打满网络。探测目标应是自有或明确允许的轻量地址，并分别记录 DNS、连接、TLS、代理认证、HTTP 与业务断言结果，方便定位问题发生在哪一层。

TTL 不能替你清理所有索引

一个容易忽略的细节是：给资源 Hash 设置 TTL，只会让这个键过期，不会自动删除 Sorted Set 中同名的 proxy_id。因此 Redis代理IP池还需要清理器，定期核对可用、冷却和观察索引，移除元数据不存在或业务失效时间已到的成员。

清理任务应分批执行，记录扫描数、删除数和孤儿索引数，避免一次遍历大池造成延迟抖动。若依赖键空间通知触发清理，也应把它当辅助信号，而不是唯一保证；服务重启、订阅中断或配置差异都可能漏掉事件。

用一张验收表判断能否上线

上线前至少验证六件事：20 个 Worker 并发领取时同一资源不会重复租出；Worker 崩溃后租约能在预期时间释放；冷却成员不会提前回流；资源 Hash 过期后孤儿索引能被清理；认证信息不会出现在日志；Redis 短暂不可用时任务停止领取新资源，而不是绕过池直接使用旧地址。

监控则关注可用池深度、租约数量、领取等待时间、冷却回流率、孤儿索引数、按错误类型统计的失败率，以及单位有效结果成本。只有资源状态、任务反馈和停止条件都能对上，Redis代理IP池才是可维护的调度组件，而不只是一个更快的地址列表。

从小规模开始时，可以先实现 Hash、可用/冷却 Sorted Set、原子租约和定时清理四个核心模块。等多项目复用、策略版本和审计需求明确后，再扩展独立 API 与事件流；这样既保留 Redis 的低延迟优势，也不会过早把简单需求做成难以运维的大系统。