python接口限流核心是控制单位时间请求量以保障稳定性，常用令牌桶（适合突发）、滑动窗口（精度高）和漏桶（匀速处理）算法，结合多级策略与可观测性。
Python接口限流的核心是控制单位时间内请求的数量，防止系统过载、保障服务稳定性。关键不在于“堵死”，而是在合理阈值内平滑调度，兼顾公平性与响应效率。
令牌桶算法：适合突发流量场景
令牌桶是最常用且易理解的限流模型。系统以固定速率向桶中添加令牌，每个请求消耗一个令牌；桶满则丢弃新令牌，无令牌则拒绝请求。
- 用 redis-py 实现分布式令牌桶：借助
INCR+EXPIRE组合模拟桶容量和重置周期，避免单点瓶颈 - 本地限流可用 functools.lru_cache 缓存时间窗口内的计数，但仅适用于单进程部署
- 注意桶容量与填充速率的配比——比如 100 QPS 可设桶大小为 200，允许短时突发，但不会长期透支
滑动窗口计数：精度高、内存开销小
相比固定窗口（如每分钟清零），滑动窗口按毫秒/秒级切分时间片，只保留最近 N 个窗口的请求计数，能更真实反映实时压力。
- 使用 Redis ZSET 存储请求时间戳，通过
ZCOUNT统计指定时间范围内的请求数 - 在 FastAPI 或 Flask 中间件里拦截请求，先查后判，超限立即返回
429 Too Many Requests - 适合对限流精度要求高的支付、登录等敏感接口
漏桶算法：强调请求匀速处理
漏桶更侧重“削峰填谷”，请求入队后以恒定速率流出执行。它天然抑制突发，但无法应对短时激增，适合后台任务类接口。
立即学习“Python免费学习笔记（深入）”；
- Python 中可用 asyncio.Queue 搭配定时协程实现轻量漏桶，配合
maxsize控制缓冲区上限 - 生产环境建议结合 Celery + Redis，将请求转为延迟任务，由 worker 匀速消费
- 注意设置合理的队列超时，避免请求长时间等待或堆积失败
多级限流策略：按需组合更可靠
单一算法难覆盖所有场景，推荐分层控制：接入层（Nginx）做粗粒度 IP 限流，应用层（Python）做用户/接口级细粒度控制，关键路径再叠加业务规则（如单用户每小时最多调用 5 次下单接口）。
- 用装饰器封装限流逻辑，例如
@rate_limit(key_func=get_user_id, max_calls=100, period=60) - 记录被限流日志（含 IP、用户 ID、接口路径），便于后续分析异常调用模式
- 对管理员或白名单用户可动态绕过限流，通过 Redis 的
SETNX标记临时豁免状态
限流不是功能终点，而是可观测性起点。配合 Prometheus 暴露限流命中数、拒绝率等指标，才能真正支撑容量规划与弹性伸缩。
