Django处理请求过程中收到新请求时的响应机制咨询

首先要明确最核心的认知：Django本身只是实现了WSGI/ASGI规范的Web框架，并不负责多个请求之间的调度逻辑，多个请求同时到达时的资源分配、是否互相影响，完全由部署时前置的应用服务器决定，和Django核心代码没有直接关系。

不同部署场景下的实际表现 #

• 生产环境同步部署（最常用场景）
  线上跑同步Django基本都用Gunicorn、uWSGI这类WSGI服务器，启动时会按配置拉起固定数量的工作进程/线程，每个工作单元同一时间只能处理1条请求。新请求到达时如果有空闲工作单元，就会被分配到独立单元处理，和正在处理的其他请求完全内存隔离，正在处理中的请求不会被新请求打断，会按正常逻辑走完路由、视图、中间件流程返回对应response。如果所有工作单元都被占满，新请求会进入服务器的等待队列排队，等前面的请求处理完释放资源后再被调度，完全不会影响已经在处理中的请求。
  唯一的例外是代码编写不规范，乱改全局变量、跨请求共享的类属性这类公共内存数据，才会出现多请求数据互相污染、response内容错乱的问题，这属于代码并发安全bug，不是框架或服务器的规则问题。
• 生产环境异步部署
  用Daphne、Uvicorn这类ASGI服务器跑异步Django视图时，单个异步工作线程可以在IO等待阶段（比如查数据库、调第三方接口等被await标记的操作）切换去处理其他就绪的新请求。注意这个切换只会发生在IO等待的空档，不会强行打断正在执行CPU密集计算的请求逻辑。这种模式下正在处理的请求同样会正常走完流程返回response，不会因为新请求进来丢失或返回异常，只是把IO等待的空闲时间利用起来处理其他任务，提升整体吞吐量。
• 本地开发服务器模式
  平时本地调试跑的python manage.py runserver是简化的调试用服务器，默认单线程逻辑下同一时间只能处理1条请求，新请求必须等当前请求完全处理完、返回response之后才会被调度，如果当前请求卡死后头的请求全得排队等待。如果启动时加了--nothreading参数更是完全串行处理。注意这个服务器仅用于本地调试，性能和调度逻辑都不满足生产要求，绝对不要拿它的表现推断线上场景。

特殊规则说明 #

• 不管有没有新请求到达，只要单个请求处理时长超过应用服务器配置的超时阈值，服务器都会主动终止这个请求的处理，返回超时响应，这个逻辑和并发请求数无关。
• 如果用多进程工作模式，单个进程崩溃只会影响当前进程正在处理的请求，其他进程处理的请求完全不受影响，服务器会自动拉起新的工作进程补位。

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