接口限流算法对比解析

本文深入剖析了Python Web接口限流的核心实践难题，指出令牌桶算法凭借对突发流量的友好支持、配置灵活性及Redis实现的简洁性，显著优于易误限流且分布式下精度堪忧的漏桶算法；同时强调原子性保障必须依赖Lua脚本封装Redis操作，警示fastapi-limiter中key_func配置不当会导致全局限流灾难，并揭露内存限流在多进程Web服务中的本质失效风险——真正挑战不在于算法选择，而在于唯一安全的限流标识设计、非阻塞的Redis调用优化，以及面向生产环境的热更新限流策略落地。

令牌桶和漏桶，哪个更适合 Python Web 接口

令牌桶更灵活、更常用，尤其适合突发流量场景；漏桶严格匀速，容易在真实业务中造成误限流。Python 生态里 slowapi、fastapi-limiter 默认都用令牌桶，不是偶然。

原因很简单：Web 接口常有短时峰值（比如秒杀开场、定时任务触发），漏桶会把本可处理的请求直接挡掉；而令牌桶允许“借”几个令牌先扛住，只要后续填得上，就不伤体验。

• token_bucket 的 capacity 和 refill_rate 可调，能适配不同接口的容忍度（比如登录接口严一点，查询接口松一点）
• 漏桶的 leak_rate 一旦设死，就难兼顾“快响应”和“防刷”，改一次要全量重启
• Redis 实现漏桶需额外维护“上次漏水时间”，精度依赖系统时钟，分布式下易出错；令牌桶只需原子增减一个计数器，INCRBY + EXPIRE 就够

用 redis-py 手写限流时，eval 脚本为什么不能少

不加 Lua 脚本，GET + INCR + EXPIRE 三步操作在并发下会失效——多个请求同时读到 0，又各自 INCR 成 1，结果放行了 5 个本该被限的请求。

必须用 eval 把判断和更新包成原子操作。别信“我只用单线程 Flask 就没事”，HTTP 服务器（如 Uvicorn）默认开多 worker，Redis 连接是共享的。

• 脚本里要用 redis.call("INCR", key) 而不是 redis.call("GET", key) 再 INCR，否则还是有竞态
• 记得 EXPIRE 放在 INCR 后面，且只对新 key 生效（if ttl == -1 then redis.call("EXPIRE", key, expire_s) end）
• 返回值建议设计成：-1 表示拒绝，>=0 表示剩余令牌数，方便前端做降级提示

fastapi-limiter 的 key_func 写错会导致全局限流

默认 key_func 是按路径限流，所有用户共用一个桶。你要按用户限流，却忘了重写这个函数，结果 A 用户刷爆了，B 用户跟着 429 —— 这不是 bug，是配置没到位。

常见错误写法：key_func=lambda request: request.url.path，看起来没错，但漏掉了身份标识。

• 需要从 request 提取唯一标识：JWT 用 request.state.user_id（前提是中间件已解析并挂载），Session 用 request.cookies.get("session_id")
• 注意空值处理：匿名用户建议用 request.client.host + request.headers.get("user-agent") 拼接，避免空字符串导致 key 冲突
• 如果用了 Depends 注入依赖，key_func 里不能直接调用依赖函数，得提前在路由层 resolve 好再传进去

内存限流（ratelimit 库）在生产环境为什么不敢用

因为它是基于 threading.local 或全局 dict 实现的，每个进程一份状态。Uvicorn 开 4 个 worker，同一 IP 的请求打到不同进程，限流就形同虚设。

除非你确定永远只跑单进程（比如本地调试、CLI 工具），否则别在 Web 服务里用 ratelimit 或 limits 的内存后端。

• 查文档会发现它支持 Redis，但默认不启用——必须显式传 storage="redis://..."，且版本 >= 2.0
• 旧项目若混用 limits 1.x 和 Redis，可能因序列化方式不一致导致 key 解析失败，报 ValueError: not enough values to unpack
• 内存限流唯一靠谱的场景：异步任务内部的子调用节流（比如 Celery 里限制调第三方 API 的频率），此时单进程上下文可控

真正麻烦的从来不是选算法，而是怎么让 key 既唯一又安全、怎么让 Redis 调用不拖慢主流程、还有——当运维说“限流开关要能热更新”，你得想清楚配置项到底该放 etcd 还是 Redis Hash。

本篇关于《接口限流算法对比解析》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！