UWSGI环境下Django接收POST请求fork子进程执行慢任务重定向失效问题

问题根因 #

该问题的核心原因是uWSGI的请求响应socket文件描述符会被multiprocessing.Process fork出来的子进程继承，uWSGI默认会等待所有持有该socket的进程关闭描述符后，才会将响应发送给客户端，所以表现为浏览器一直等到子进程执行完才收到重定向。
你配置的close-on-exec=true仅对通过exec系统调用创建的子进程生效，Python multiprocessing默认使用fork模式创建进程，不会触发exec逻辑，因此该配置对你的场景不生效。

解决方案 #

• 方案1：调整uWSGI配置，新增lazy-apps = true参数，同时保留原有close-on-exec=true配置即可。该配置会让每个uWSGI worker进程独立加载Django应用，而非由master进程预加载后fork给worker，可大幅减少子进程继承的多余文件描述符，绝大多数场景下可直接解决响应阻塞问题，仅会带来可忽略的轻微内存开销。
• 方案2：修改子进程创建逻辑，使用两次fork生成孤儿进程，完全断开子进程和uWSGI worker的关联，参考代码如下：

import os
import sys
from django.shortcuts import redirect

def your_post_view(request):
    if request.method == "POST":
        # 第一次fork
        pid = os.fork()
        if pid > 0:
            # 原uWSGI worker进程直接返回响应
            return redirect("/your_target_path/")
        # 第一次fork生成的子进程
        os.setsid()
        # 第二次fork
        pid = os.fork()
        if pid > 0:
            # 第一次fork的子进程直接退出
            sys.exit(0)
        # 第二次fork生成的孤儿进程由系统init进程托管，执行慢任务
        your_slow_workload()
        # 任务执行完成后退出
        sys.exit(0)

• 方案3：引入专业异步任务队列处理慢任务，比如Celery、Django-Q等，彻底规避uWSGI进程和任务进程的耦合问题，同时支持任务重试、状态查询、监控等运维能力，适合慢任务较多的业务场景。

内容的提问来源于stack exchange，提问作者Denis