Redis令牌桶限流选INCR+EXPIRE而非SETNX，因INCR天然支持计数且首次返回1可触发EXPIRE设过期，避免重复重置；须用Lua脚本保证原子性，并以Redis服务端TIME实现惰性填充，响应头应设X-RateLimit-Limit等字段。
Redis 令牌桶限流为什么选 INCR + EXPIRE 而不是 SETNX
因为要原子性地「增加令牌数」和「设置过期时间」，但 Redis 没有原生命令能一步完成这两件事。用 SETNX 只能抢锁，没法计数；而 INCR 天然支持自增，配合 EXPIRE（在 key 不存在时调用）就能模拟“首次创建+设过期”的语义。
常见错误是先 INCR 再无条件 EXPIRE，结果每次请求都重置过期时间，导致限流失效。正确做法是只在 INCR 返回 1（即 key 刚被创建）时才调用 EXPIRE。
- 使用场景：单机或分布式 Web 接口限流，比如限制用户每分钟最多调用 60 次
/api/v1/order - 参数差异：
INCR对不存在的 key 自动初始化为 0 再加 1，所以首次返回 1；后续返回值就是当前累计值 - 性能影响：纯内存操作，QPS 轻松破万；但要注意避免在高并发下反复
EXPIRE，可用 Lua 脚本封装逻辑（见下一条）
Python 用 redis-py 实现原子令牌桶的推荐写法
别手写多次 INCR + EXPIRE 请求，网络往返可能被中断。直接上 Lua 脚本，由 Redis 服务端保证原子性。
示例脚本（传入 key、最大令牌数、填充速率、时间窗口）：
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
local current = redis.call("INCR", KEYS[1])
if current == 1 then
redis.call("EXPIRE", KEYS[1], tonumber(ARGV[1]))
end
if current > tonumber(ARGV[2]) then
return 0
end
return 1
Python 中调用：
- 用
redis_client.register_script(...)预编译，避免每次传输脚本 -
ARGV[1]是窗口秒数（如 60），ARGV[2]是最大令牌数（如 60） - 返回 1 表示放行，0 表示拒绝；注意它不自动填充令牌，只是基础版——真正动态填充需额外定时任务或惰性计算
令牌桶“动态填充”怎么在 Redis 里低成本实现
严格令牌桶要求每秒/毫秒自动加若干令牌，但 Redis 没有后台定时器。常见方案是「惰性填充」：每次请求时，根据距离上次更新的时间差，算出该补多少令牌，再更新值。
这必须用 Lua 完成，否则 GET + 计算 + SET 三步非原子，高并发下会丢令牌或超发。
- 关键点：用
HGETALL或两个独立 key 存「当前令牌数」和「最后更新时间戳」，Lua 里用redis.call("TIME")获取服务端时间 - 容易踩的坑：客户端时间不准、网络延迟导致时间戳误差；一律以 Redis 服务端
TIME为准 - 兼容性影响：Redis 6.0+ 支持
TIME命令，老版本需改用redis.call("INCR", "dummy")配合服务器时间预估（不推荐）
Flask/FastAPI 中拦截请求时，429 Too Many Requests 的响应头怎么设才合理
光返回状态码不够，前端或网关需要知道还能等多久、当前剩余配额。HTTP 标准建议用 X-RateLimit-Limit、X-RateLimit-Remaining 和 Retry-After。
-
X-RateLimit-Limit：固定值，比如 60 -
X-RateLimit-Remaining：从 Lua 脚本返回的剩余令牌数（注意：若用惰性填充，这个值得在 Python 层再算一次） -
Retry-After：如果拒绝，填整数秒（如 60），表示 X 秒后重试；不要填带小数的秒或时间戳 - 性能影响：每个响应都加 header 几乎无开销，但别在日志里重复打印这些字段，容易撑爆日志系统
复杂点在于「剩余令牌数」的获取时机——它不能简单等于 Lua 返回值，因为惰性填充后实际值已变；最稳的方式是在 Lua 里把新值也 RETURN 出来，Python 层直接透传。
