应使用带时间戳前缀的固定窗口键名（如rate:api_v1:1717027200）配合Lua脚本原子执行INCR+EXPIRE，并在脚本中直接判断计数值是否超限，返回当前值与剩余等待秒数，避免竞态与窗口错位。
Redis 计数器怎么设才不会漏计或重复计？
直接用 INCR 不够——多个爬虫实例并发调用时，若请求在 EXPIRE 前集中到达，可能触发「窗口滑动错位」：比如每分钟最多 60 次，但第 59 秒和第 1 秒各来 30 次，实际跨了两个窗口却只被算作一次过期，导致瞬时超限。
正确做法是用「固定时间窗口 + 原子操作」组合：
- 键名带时间戳前缀，例如
f"rate:api_v1:{int(time.time() // 60)}"，确保所有实例对同一分钟窗口写入同一个 key - 用
pipeline执行INCR+EXPIRE（注意EXPIRE必须在INCR后立即执行，否则新 key 可能被误删） - 检查返回值：若
INCR结果 > 60，则拒绝本次请求，不走后续逻辑
Python 里怎么原子判断并限流？别用两次 redis.get()
常见错误是先 get 再 incr，中间存在竞态：两个进程同时读到 59，都执行 incr，结果变成 61 —— 但只有一方该被拒绝。
必须用 Lua 脚本或 Redis 原生命令保证原子性：
立即学习“Python免费学习笔记（深入）”；
- 推荐用
eval执行内联脚本，例如：lua local current = redis.call("INCR", KEYS[1]) if current == 1 then redis.call("EXPIRE", KEYS[1], ARGV[1]) end return current - 在 Python 中调用：
redis_client.eval(lua_script, 1, key, window_seconds) - 注意：Lua 脚本中不能用
redis.call("GET", ...)判断阈值，应直接用current > limit做返回判断，避免多一次 round-trip
不同爬虫任务需要独立限流，key 设计怎么兼顾可读性和性能？
把 URL、User-Agent、IP 全拼进 key 看似精确，但会导致 key 过多、内存膨胀，且无法应对代理池轮换场景。
更实用的分组策略：
- 按业务维度隔离：如
rate:shop_listing:1m、rate:product_detail:5s，便于监控和调整 - 如需按 IP 限流，用哈希取模降级：
f"rate:ip:{ip_hash % 100}"，避免单个恶意 IP 打爆一个 key - 避免在 key 中存动态参数（如时间戳毫秒级），会极大增加 key 数量；窗口粒度统一用秒级整除即可
限流后怎么让爬虫知道该等多久再试？别硬 sleep
单纯 time.sleep(1) 效率低，且无法感知窗口重置时间点。
应该让 Redis 返回剩余等待秒数：
- 在 Lua 脚本中计算：
return {current, math.max(0, window_seconds - (tonumber(ARGV[2]) % window_seconds))}，其中ARGV[2]是当前秒级时间戳 - Python 中解析返回值，若
current > limit，则sleep(remaining_seconds) - 注意：客户端时间可能不准，更稳妥的是让脚本用
redis.call("TIME")获取服务端时间，但会略增延迟；多数场景用客户端时间 + 1 秒缓冲已足够
Redis 的原子性只在单个命令或 Lua 脚本内成立，跨 key 操作（比如同时更新计数器和日志队列）依然要小心事务边界。真正难的不是写对一次限流，而是当有 20 个不同优先级的任务共用一套 Redis 时，如何让它们的 key 不冲突、TTL 不互相覆盖、失败重试不放大流量——这些得靠命名规范和上线前的压测验证，而不是靠文档里的一行代码。
