Python Flask用Semaphore控制并发执行数

在Flask中使用Semaphore控制并发看似简单，实则暗藏多重陷阱：threading.Semaphore仅对同步视图有效，async视图必须改用asyncio.Semaphore；而当部署到多worker的gunicorn环境时，两者均失效，需升级为Redis分布式限流或nginx层限速；更关键的是，acquire/release若未配对（尤其缺少timeout和finally保障），极易引发请求卡死、504超时与雪崩式故障——并发控制不是加一行代码就万事大吉，而是必须精准匹配视图类型、执行模型与部署架构的系统性工程。

Flask里用threading.Semaphore控制并发数，真能生效吗？

能，但只对同步视图函数有效；如果你用了async def或await，threading.Semaphore完全不起作用——它锁的是线程，不是协程。Flask默认走Werkzeug的同步WSGI流程，所以多数场景下它确实管用，前提是你的视图没混进异步逻辑。

实操建议：

• 全局定义一个Semaphore实例，比如sem = threading.Semaphore(5)，限制最多5个并发请求同时执行业务逻辑
• 在视图函数开头调用sem.acquire()，结尾务必sem.release()（推荐用try/finally包住）
• 别在before_request里acquire、after_request里release——中间出错会导致信号量永远卡死

为什么async视图不能用threading.Semaphore？

因为threading.Semaphore是阻塞式同步原语，而await不会让出线程控制权给它；你调用acquire()时整个协程会卡住，但事件循环还在跑，其他协程照常调度，结果就是并发数失控，甚至引发超时雪崩。

实操建议：

• 异步视图必须换asyncio.Semaphore，初始化写成sem = asyncio.Semaphore(5)
• 用await sem.acquire()和sem.release()（注意：不是await sem.release()）
• 确保整个请求生命周期都在同一个asyncio事件循环中——Flask原生不支持异步中间件，before_request这类钩子仍是同步的，别在里面碰asyncio.Semaphore

gunicorn多worker下，Semaphore还有效吗？

无效。每个gunicorn worker是独立进程，threading.Semaphore和asyncio.Semaphore都只在当前进程内生效。设了--workers 4再配Semaphore(5)，实际峰值并发就是4 × 5 = 20。

实操建议：

• 如果真要跨进程限流，得换分布式方案：用Redis + redis-py的redis.Redis().setnx()或redis.Redis().eval()脚本实现原子计数
• 或者直接上nginx层限速（limit_req），更轻量且不依赖应用逻辑
• 别试图用multiprocessing.Semaphore——Flask+Gunicorn下进程间共享内存难维护，容易deadlock

常见错误现象：请求卡死、504、日志里反复出现TimeoutError

典型表现是前端等几十秒后报超时，日志里看不到业务逻辑打印，但acquire()前的日志有，acquire()后的没有。大概率是release()漏写了，或者acquire()时没设timeout参数，导致永久阻塞。

实操建议：

• 永远给acquire()加timeout=3（单位秒），超时抛TimeoutError，然后返回503 Service Unavailable
• 释放操作必须进finally块，哪怕业务逻辑raise了异常也不能跳过
• 用logging.debug("sem acquired, left: %d", sem._value)临时查剩余许可数（仅调试，别留线上）

并发控制不是加个Semaphore就完事——它的作用域、生命周期、部署模型，三者错一个，限流就形同虚设。最常被忽略的是：你以为锁住了接口，其实只锁住了单个worker里的某条线程。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Python Flask用Semaphore控制并发执行数》文章吧，也可关注golang学习网公众号了解相关技术文章。