Redis是唯一能低成本、跨进程共享状态的通用方案，因INCR+EXPIRE组合可实现原子限流，而本地计数器或sleep无法跨实例同步，且SQLite等数据库不支持高并发原子计数。
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 计数，精度高但开销略大。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
立即学习“Python免费学习笔记（深入）”；
- 插入请求：
zadd "rate:uid123" <timestamp> "req_12345" - 清理旧数据：
zremrangebyscore "rate:uid123" 0 <now-60> - 获取当前请求数：
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 延迟突增、连接闪断、时钟不同步时，你的限流还能不能稳住阈值——这些边界情况，比语法细节更容易让分布式爬虫在凌晨三点突然被封号。
