Python爬虫应对分布式限流，Redis实现请求限制

本文深入剖析了Python爬虫在分布式场景下如何借助Redis实现高可靠、低开销的请求限流，直击本地计数器和time.sleep等方案在跨进程同步、并发一致性及临界窗口问题上的根本缺陷；通过原子性Lua脚本封装INCR+EXPIRE解决过期漏设风险，用ZSET构建精准滑动窗口应对突发流量，并强调连接池配置、超时控制与故障降级等生产级细节——真正决定爬虫稳定性的，不是语法正确性，而是面对Redis延迟、时钟漂移、网络闪断等真实异常时，限流系统能否依然守住阈值底线。

Redis 是唯一能低成本、跨进程共享状态的通用方案，其他方式（如文件锁、数据库计数）在高并发下要么性能差，要么不一致。直接用 INCR + EXPIRE 组合就能实现基础限流，但要注意原子性、边界和时钟漂移问题。

为什么不能只用 time.sleep() 或本地计数器

单机限速对分布式完全无效：多个爬虫实例各自 sleep，总请求量照样爆表；本地变量或内存字典无法被其他进程感知，counter += 1 在多进程里等于没加。Redis 的原子操作是跨节点同步的唯一可靠手段。

• 本地计数器在 fork 或多进程启动后各自独立，没有共享上下文
• time.sleep(1) 只控制“发出请求”的节奏，不控制“单位时间请求数”，遇到重试、超时、异步并发就失效
• SQLite 等嵌入式数据库写入慢、不支持高并发 INCR，且无法跨机器访问

INCR + EXPIRE 必须配对使用，否则会漏过期

Redis 的 INCR 不自带过期逻辑，如果只做 INCR 而忘记设过期，key 会永久存在，导致后续所有判断都失败。必须在首次 INCR 后立刻 EXPIRE，且需用 Lua 脚本保证原子性——否则并发写入时可能覆盖过期时间。

• 错误写法：redis.incr("rate:uid123"); redis.expire("rate:uid123", 60) —— 中间可能被其他客户端读取到未过期的 key
• 正确做法：用 Lua 脚本一次性完成「增+设过期+取值」，例如：

  local current = redis.call("INCR", KEYS[1])<br>if current == 1 then<br>  redis.call("EXPIRE", KEYS[1], ARGV[1])<br>end<br>return current

• 脚本调用：redis.eval(lua_script, 1, "rate:uid123", 60)

滑动窗口比固定窗口更准，但得用 ZSET

固定窗口（每分钟清零）有临界问题：比如用户在第 59 秒发了 10 次请求，第 60 秒又发 10 次，实际 2 秒内就超限，但固定窗口检测不到。滑动窗口用 ZSET 存储每个请求的时间戳，每次查询前先 ZREMRANGEBYSCORE 清理过期项，再 ZCARD 计数，精度高但开销略大。

• 插入请求：zadd "rate:uid123" "req_12345"
• 清理旧数据：zremrangebyscore "rate:uid123" 0
• 获取当前请求数：zcard "rate:uid123"
• 注意：timestamp 必须用秒级或毫秒级整数，避免浮点精度问题

别忽略 Redis 连接池和超时配置

高频限流场景下，Redis 连接建立/销毁本身就会成为瓶颈。不配连接池，每秒几百次 INCR 可能直接打满 socket 或触发超时；而默认无超时，某个节点网络卡顿时整个爬虫线程会阻塞。

• 必须设置 socket_connect_timeout 和 socket_timeout（建议均 ≤ 0.5 秒）
• 用连接池：redis.ConnectionPool(max_connections=20, ...)，避免每次新建连接
• 生产环境禁用 redis.Redis(host="localhost") 这种直连，要走连接池实例
• 如果 Redis 故障，限流逻辑应降级为“放行”而非报错阻塞，否则整个爬虫停摆

真正难的不是写对那几行 INCR，而是当 Redis 延迟突增、连接闪断、时钟不同步时，你的限流还能不能稳住阈值——这些边界情况，比语法细节更容易让分布式爬虫在凌晨三点突然被封号。

到这里，我们也就讲完了《Python爬虫应对分布式限流，Redis实现请求限制》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！