Flask结合multiprocessing的WSGI部署方案及并行有效性确认

• 只要你是用multiprocessing.Process创建独立子进程，或是用multiprocessing.Pool管理进程池来执行视频处理任务，那就是真正的硬件级并行。因为Python的GIL（全局解释器锁）仅限制多线程的CPU并行，多进程模式下每个子进程拥有独立的解释器和内存空间，完全能利用多核CPU的硬件资源。
• 验证方式：
  • 运行任务时打开系统监控工具（Windows任务管理器、Linux/macOS的htop），如果多个CPU核心占用率同时上升，说明并行生效。
  • 对比单进程和多进程处理相同视频集合的耗时，多进程版本耗时应接近单进程耗时除以核心数（忽略进程调度的微小开销）。
• 避坑提醒：如果误用了multiprocessing.dummy（本质是线程池，仍受GIL限制），那不算真正的多进程并行，务必使用原生multiprocessing模块的进程类或池。

WSGI服务器（如Gunicorn、uWSGI）本身支持多进程部署，结合你的multiprocessing逻辑，需注意以下关键点：

1. 避免进程数量爆炸 #

不要在每个请求处理函数内临时创建Pool或Process——如果WSGI服务器已开启多个worker进程，再在每个worker内生成子进程，会导致进程总数失控，反而降低性能。建议在Flask应用启动时初始化全局进程池，所有请求共享这个池提交任务。

调整后的示例代码 #

from flask import Flask, request
import multiprocessing
import your_video_processing_module

app = Flask(__name__)
# 进程池大小建议设为CPU核心数或核心数-1，避免资源耗尽
pool = multiprocessing.Pool(processes=multiprocessing.cpu_count())

@app.route('/process-video', methods=['POST'])
def process_video():
    video_path = request.json.get('video_path')
    # 异步提交任务到进程池，如需同步等待结果可调用result.get()
    task = pool.apply_async(your_video_processing_module.process_video, args=(video_path,))
    return {'status': 'processing', 'task_id': task._job}

if __name__ == '__main__':
    app.run()

2. 选择WSGI服务器部署 #

Gunicorn部署 #

• 安装：pip install gunicorn
• 启动命令：gunicorn --workers 2 --threads 1 your_flask_app:app
  • --workers：WSGI worker进程数，建议设为CPU核心数的1-2倍（如果视频处理已用多进程，worker数不宜过多，避免进程竞争）。
  • --threads 1：因为依赖multiprocessing做并行，无需WSGI线程支持，设为1即可。

uWSGI部署 #

• 安装：pip install uwsgi
• 创建配置文件uwsgi.ini：

[uwsgi]
module = your_flask_app:app
master = true
processes = 2
threads = 1
socket = 0.0.0.0:5000
protocol = http

• 启动命令：uwsgi --ini uwsgi.ini

3. 部署注意事项 #

• 资源管控：视频处理对CPU、内存消耗大，需根据服务器硬件调整worker数和进程池大小，避免内存耗尽。
• 任务稳定性：如果是大规模异步处理，建议引入专业任务队列（如Redis+Celery），比原生multiprocessing更可靠，能避免WSGI重启时丢失任务；轻量场景用全局进程池即可。
• 进程自愈：WSGI worker意外重启时，要确保进程池能重新初始化，避免使用失效的池实例。

内容的提问来源于stack exchange，提问作者Muhammad Ikhwan Perwira