Python并发限流核心是控制任务并发数防资源过载，按场景选机制：单机用Semaphore或线程池，分布式用Redis+Lua，精细化用令牌桶算法。
Python 并发限流的核心目标是控制同时执行的任务数量，防止资源过载（如数据库连接耗尽、API 调用超频、CPU 或内存打满）。实现思路不依赖单一方案，而是按场景选择合适机制：轻量级用信号量或线程池控制并发数，分布式需引入外部协调（如 Redis），高精度限流则用令牌桶或漏桶算法。
基于 threading.Semaphore 的简单并发控制
适用于单进程内多线程/多协程（配合 asyncio）的粗粒度限流。Semaphore 本质是一个计数器，acquire() 减一、release() 加一，超出初始值时阻塞等待。
常见写法：
- 初始化 sem = Semaphore(n)，n 即最大并发数
- 每个任务执行前调用 sem.acquire()，结束后必须 sem.release()（建议用 try/finally 或上下文管理器）
- asyncio 中可用 asyncio.Semaphore，配合 async with sem: 更安全
利用 concurrent.futures.ThreadPoolExecutor 或 ProcessPoolExecutor
这是更“Pythonic”的方式——不手动管信号量，而是把限流逻辑交给执行器本身。max_workers 参数直接限制线程/进程数，底层自动排队调度。
立即学习“Python免费学习笔记（深入）”；
优势明显：
- 自带任务队列和异常传播，无需手动处理阻塞与释放
- 支持 submit() 提交单个任务，或 map() 批量分发，返回 Future 对象便于结果收集
- 适合 I/O 密集型（用 ThreadPoolExecutor）或 CPU 密集型（用 ProcessPoolExecutor）场景
分布式环境下的限流：Redis + Lua 原子操作
单机限流在微服务或多实例部署下失效，需共享状态。Redis 是常用选择，关键在于保证“检查+更新”原子性，避免竞态条件。
典型做法：
- 用 Redis 的 INCR + EXPIRE 组合模拟滑动窗口，但存在临界问题；更稳妥的是用 Lua 脚本封装整个限流逻辑
- 例如：脚本读取当前计数、判断是否超限、未超则 INCR 并设置过期时间，全程在 Redis 内原子执行
- Python 端通过 redis-py 调用 eval() 方法传入脚本和参数，返回布尔值表示是否允许通过
精细化速率控制：令牌桶（Token Bucket）实现
当需要按“QPS”或“每秒请求数”动态限流（而非单纯控并发数），令牌桶更贴切。它以恒定速率向桶中添加令牌，每次请求消耗一个令牌，桶满则丢弃新令牌。
可选实现路径：
- 单机：用 time.time() 记录上次填充时间，按间隔计算应新增令牌数，维护一个浮点数计数器
- 分布式：将桶状态存 Redis，用 Lua 更新（如 key 存 last_time 和 tokens，每次请求脚本计算并返回是否允许）
- 第三方库如 pyrate-limiter 已封装多种算法（令牌桶、漏桶、滑动窗口），支持内存/Redis 后端，开箱即用
