应使用带时间戳前缀的固定窗口键名（如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 原生命令保证原子性：

• 推荐用 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 过多、内存膨胀，且无法应对代理池轮换场景。

macOS UI 自动化技能包 —— 用 Python 控制你的 Mac

让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限

下载

更实用的分组策略：

• 按业务维度隔离：如 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 不互相覆盖、失败重试不放大流量——这些得靠命名规范和上线前的压测验证，而不是靠文档里的一行代码。

Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！